Percona Toolkit gripes welcome
What are your pet peeves about the tools? I have a lot. For example, pt-table-sync doesn’t let me do things I want it to do sometimes (and I know it could be made to do them). Another example: pt-query-digest’s tcpdump parser doesn’t pay attention to TCP sequence numbers, so sometimes it invents a really long-running query where there isn’t one. Post your gripes, big and small, in the comments!
(This blog post is an attempt to do a 37signals approach to prioritizing: the stuff people complain about repeatedly is what you should focus on. No promises about fixing the gripes — I just want to hear them!)
my two gripes are these – it’s often difficult to configure initially (different syntax or connection parameters for each tool also leading to a very difficult time with the conf files) and secondly that pt-heartbeat just never seems to be doing anything… That’s probably my fault for not really grasping the point of the tool, but I simply don’t.
Ammon
17 Apr 12 at 10:44 pm
Perl.
Harrison Fisk
18 Apr 12 at 12:59 am
Tutorials and some examples. Altogether better documentation
Joshua Dickerson
18 Apr 12 at 8:48 am
Ditto to better examples…I can use maybe 2 or 3 of the tools for some of me needs but some seem v promising for certain cases but the lack of good examples make it harder to tackle them.
Maybe a recipe book that covers some common use cases? I am sure you guys have many bases on your consulting experience. :)
Silvia Botros
18 Apr 12 at 11:47 am
There’s some discussion about examples, docs, tutorials etc here:
http://www.mysqlfanboy.com/2012/04/percona-tease-kit/
Maybe Mark would be interested in collaborating.
Xaprb
18 Apr 12 at 12:09 pm
pt-cookbook needed?
Andrew Moore
18 Apr 12 at 12:30 pm
I have a lot of problems with pt-index-usage killing the database. Although I like the tool very much and limit its scope to prevent it doing so.
pt-query-digest does sometimes OOM – usually with very long/blob queries.
I wrote about it here:
http://www.jonathanlevin.co.uk/2012/04/mastering-mysql-indexing.html
Jonathan Levin
18 Apr 12 at 1:25 pm
When running tools when you need to give password on the command line for connection need to repeatedly provide password rather than just once. There are work around for this such as defining it in a my.cnf file. But feel this should be handled gracefully on the command line as well.
mysql02 libexec]# pt-mysql-summary — -p
Enter password:
Enter password:
Enter password:
Enter password:
Enter password:
Enter password:
Enter password:
Enter password:
Enter password:
Enter password:
Enter password:
Enter password:
Enter password:
Enter password:
Enter password:
Enter password:
# Percona Toolkit MySQL Summary Report #######################
System time | 2012-04-18 17:46:58 UTC (local TZ: PDT -0700)
# Instances ##################################################
Port Data Directory Nice OOM Socket
===== ========================== ==== === ======
Taylor
18 Apr 12 at 1:50 pm
The command line help options need to be more verbose in some cases. For example, pt-query-digest –group-by option:
–group-by=A Which attribute of the events to group by
(default fingerprint)
The list of attributes (fingerprint, tables, etc) doesn’t seem to be available except by looking at the source. You might think that the attributes are the ATTRIBUTES mentioned in the manual (which links to here: http://code.google.com/p/maatkit/wiki/EventAttributes) but those aren’t the same attributes, unless ‘tables’ is missing from the list.
Justin Swanhart
18 Apr 12 at 2:00 pm
I have to add another vote against Perl. Getting it in some production environments is a big hurdle. :-)
Razvan Musaloiu-E.
18 Apr 12 at 11:10 pm
I’m still happy with the choice of Perl. It’s always easy to think the grass is greener on the other side, but Python has its own problems with versioning, C has to be compiled, etc, etc. I have found Perl to be more universally available and functioning than any other language on systems that I am required to parachute into and rescue. There are specific tools where I would like much better performance than Perl can offer, though.
Xaprb
19 Apr 12 at 7:38 am
I mentioned both of these to you at the conference last week, so you’ve probably already got them on your list, but just to be sure:
1) pt-online-schema-change refuses to run on any tables with triggers on them, even if they are just “before” triggers. Since pt-online-schema-change only uses “after” triggers, it should work fine on tables with “before” triggers.
2) The documentation for pt-heartbeat recommends using the MEMORY storage engine, which is actually not the ideal choice. Please update the docs with a more useful recommendation (I’m assuming you recommend InnoDB here, but if you prefer MyISAM I’d be interested to know why).
Ike Walker
19 Apr 12 at 12:07 pm
It would be nice if pt-stalk let you add arbitrary collectors, or at least if it included the following:
SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCKS;
and
SELECT r.trx_id waiting_trx_id,
r.trx_mysql_thread_id waiting_thread,
r.trx_query waiting_query,
b.trx_id blocking_trx_id,
b.trx_mysql_thread_id blocking_thread,
b.trx_query blocking_query
FROM information_schema.innodb_lock_waits w
INNER JOIN information_schema.innodb_trx b ON
b.trx_id = w.blocking_trx_id
INNER JOIN information_schema.innodb_trx r ON
r.trx_id = w.requesting_trx_id;
From: http://dev.mysql.com/doc/refman/5.5/en/innodb-information-schema-transactions.html#innodb-information-schema-examples
Gavin Towey
20 Apr 12 at 3:02 pm
pt-online-schema-change used to have an option to disable replication of the changes. In the new version this option is missing. I know its not good idea to have different table structure with replication, but sometimes it is ok if you know what you’re doing.
Mihail Manolov
23 Apr 12 at 6:28 pm
We get a lot of requests to add features to disable binary logging. Through bitter, bitter, bitter experience we have learned that this is a sure way to completely destroy a percentage of users’ data. Did I mention “bitter” experience? Be careful what you wish for.
Xaprb
24 Apr 12 at 10:22 am
Gavin, pt-stalk includes a query against those tables and stores the results into the TS-lock-waits file. Can you check that and see if it does what you need? If not, explain more? If you search the source for “INNODB_LOCKS” you will see we execute two queries agains the tables, actually.
I’ve made a note about having arbitrary collectors. Good idea.
Xaprb
24 Apr 12 at 10:29 am
Ike, yes, thanks — I have those noted now.
Xaprb
24 Apr 12 at 10:29 am
Hey Baron,
I’m looking at both 2.0.4 and 2.1.1 and I see the query that uses innodb_locks similar to the one from the manual — That’s good to know. But I don’t see a second query on it.
Thanks for the response! I still like having the full output of the INNODB_LOCKS table =)
Gavin Towey
24 Apr 12 at 4:26 pm
pt-table-sync –print –ask-pass h=foo.local > diff.sql
Errors and prompts seem to be piped in (e.g.: prompt for password)
Justin Rovang
25 Apr 12 at 5:01 pm