Percona Toolkit 2.2.9 is now available

Percona is glad to announce the release of Percona Toolkit2.2.9 on July 10, 2014 (downloads are available here and from the Percona Software Repositories). This release is the current GA (Generally Available) stable release in the 2.2 series.

Bugs Fixed:

Fixed bug 1335960: pt-query-digest could not parse the binlogs from MySQL 5.6 because the binlog format was changed.

Fixed bug 1315130: pt-online-schema-change did not find child tables as expected. It could incorrectly locate tables – tables which reference a table with the same name in a different schema, and could miss tables referencing the altered table – if they were in a different schema..

Fixed bug 1335322: pt-stalk would fail when variable or threshold was a non-integer.

Fixed bug 1258135: pt-deadlock-logger was inserting older deadlocks into the deadlock table even if it was already there, therby creating unnecessary noise. For example, if the deadlock happened 1 year ago, and MySQL keeps it in the memory, pt-deadlock-logger would INSERT it into percona.deadlocks table every minute until server was restarted. This was fixed by comparing with the last deadlock fingerprint before issuing the INSERT query.

Fixed bug 1329422: pt-online-schema-changeforeign-keys-method=none can break FK constraints in a way that is hard to recover from. Although this method of handling foreign key constraints is provided so that the database administrator can disable the tool’s built-in functionality if desired, a warning and confirmation request when using alter-foreign-keys-method “none” has been added to warn users when using this option.

About Hrvoje Matijakovic

Comments

I use percona-toolkit quite heavily and especially tools like pt-online-schema-change are much appreciated.

It’s good to push out bug fixes but you’re missing something very important, and I think you need to take this into account. I run pt-online-schema-change from a wrapper to take local environment issues into account and it’s necessary due to recent changes to have to patch the behaviour. In my case adding things like: —nocheck-plan —nocheck-replication-filters.

There’s supposed to be a golden rule when pushing out minor version changes and you’ve broken that. Do not make incompatible changes: just make bug fixes, or potentially performance enhancements.

If you want to improve the product, or make it better, then bring out a new major version and we can check what has changed and if we need to use the tool differently etc.

Failing to follow that rule means that people will suddenly find things don’t work as before and then have to check _everything_ for possible incompatible changes or breakages, something that’s time-consuming and so prevents the bug fixes or performance improvements (we’re interested in) from being usable.

I’m sure this is done in good faith, but please bear it in mind, and if that means that you rollout a new 2.X every 6 months that’s fine.

Percona is not the only company to fall into this trap, but I’ve just been bitten by it so it seemed good to mention it. Other companies do this too.

In the end the MySQL environment is moving very quickly. I think it’s better to have a fast release cycle even if the changes from version X to version Y are not that large as it that gives us time to see what changes take place, whether they are important, and whether to move up immediately or not.