September 2, 2014

XtraBackup 1.6.4 respin

Very shortly after the XtraBackup 1.6.4 binaries hit the downloads site and repositories, it was found to have a bug where the master information was not properly stored, thus breaking point in time recovery and the ability to start a slave from a backup.

This was caught and fixed really quickly and we’ve re-spun the XtraBackup 1.6.4 binaries to include this fix. Since we include the BZR revision number in the versions, you will see that 1.6.4-314 replaces 1.6.4-313. The gap to get a faulty binary was very small, so not many people should be affected.

The sad-but-funny part of all this? We have very nice automated testing for exactly this problem in our new QA infrastructure that goes live this week, shortly after the 1.6.4 release. i.e. if we were a week quicker in deploying our new infrastructure or delayed our 1.6.4 release a week, we would have caught this before we even handed the tree over to be packaged.

You can find out if you were one of the few unlucky people to get the old binaries in one of a number of ways:

  1. Your package is version 1.6.4-313 instead of 1.6.4-314
  2. The command below returns a matching line:
  3. A backup produced with the faulty version will have “xtrabackup ping 5″ in the xtrabackup_binlog_info file

As I mentioned before, the time period of getting the faulty build was very small, we already had in place all the steps needed for this not to happen and if you are using YUM or APT to manage packages, everything will automatically be taken care of for you even if you did initially get the faulty build.

For reference, the bug report is here.

About Stewart Smith

Stewart Smith has a deep background in database internals including MySQL, MySQL Cluster, Drizzle, InnoDB and HailDB. he is also one of the founding core developers of the Drizzle database server. He served at Percona from 2011-2014. He is a former Percona employee.

Comments

  1. Benedikt Böhm says:

    Re-releasing the same version with different content/checksums is the worst thing you can do for downstream package maintainers. Please don’t do it again. Nobody would have gotten hurt with a 1.6.5 release.

  2. This is what we’ll do in the future if anything like this happens again.

Speak Your Mind

*