Percona is glad to announce the release of Percona Toolkit 2.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
deadlocktable 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 wouldINSERTit intopercona.deadlockstable every minute until server was restarted. This was fixed by comparing with the last deadlock fingerprint before issuing theINSERTquery. - Fixed bug 1329422: pt-online-schema-change
foreign-keys-method=nonecan 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.
Percona Toolkit is free and open-source. Details of the release can be found in the release notes and the 2.2.9 milestone at Launchpad. Bugs can be reported on the Percona Toolkit launchpad bug tracker.
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.
Hello Simon,
Thank you for taking time to contribute your experience. Your advice makes sense and will be taken in consideration for future releases.