Dear Community,

As of today release 0.9.5rc is available.

In this release there are following changes:

  • Option –no-lock is added to innobackupex-1.5.1. Use it only while ALL your
    tables are InnoDB and you DO NOT CARE about binary log
    position of backup
  • XtraBackup is ported for InnoDB Plugin 1.0.4. Barracuda file format as well as compressed tables are supported. We thank a well known Social Network site for the sponsorship.
  • Windows conscious change more
  • Impoved error messages in innobackupex
  • Windows conscious experimental change
  • Suppress purge when –stats
  • Build number in RPM name. For instance, in the name xtrabackup-0.9.5rc-50.rhel5.x86_64.rpm 50 is the build number.
  • Suppress master_thread ibuf operations for –stats
  • Suppress ibuf operations for –stats
  • fFx fatal bug at –backup when added –stats
  • New option –stats to gather index stats
  • Fixed some bugs for a 32bit platform

Fixed bugs:

The binary packages for RHEL4,5, Debian, FreeBSD, MacOS as well as source code of the XtraBackup is available on https://www.percona.com/mysql/xtrabackup/0.9.5rc/.

The Debian package is also available via APT. Just add these lines  in /etc/apt/sources.list

Update the local database

And install xtrabackup

The project lives on Launchpad : https://launchpad.net/percona-xtrabackup and you can report bug to Launchpad bug system:
https://launchpad.net/percona-xtrabackup/+filebug. The documentation is available on our Wiki.

For general questions use our Pecona-discussions group, and for development question Percona-dev group.

For support, commercial and sponsorship inquiries contact Percona.

Share this post

Comments (13)

  • Mark Callaghan

    Great work. I have sent this to you via email, but I will repeat it here. The patch here — http://bugs.mysql.com/bug.php?id=48124 — might provide a non-blocking equivalent of FLUSH TABLES WITH READ LOCK to get the binlog position on a master.

    October 25, 2009 at 9:10 am
  • Csfor

    What does hotbackup mean? Can Xtrabackup hotbackup tool work perfectly while MySQL running heavy workload? I met MySQL crashes when running workloads on the recovered data by Xtrabackup.

    October 25, 2009 at 11:21 pm
  • Aleksandr Kuzminsky

    XtraBackup can take backups while MySQL is running indeed.
    You can make it perfect if you report bugs on https://bugs.launchpad.net/percona-xtrabackup/+filebug

    October 26, 2009 at 1:53 am
  • Nils

    “Barracuda file format as well as compressed tables are supported. ”

    Does that mean that didn’t really work beforehand?

    October 26, 2009 at 8:12 am
  • Sheeri K. Cabral (Pythian)

    Csfor — both InnoDB hot backup and Xtrabackup are “warm” backups — they do take some resources, but even on busy servers I haven’t seen crashing — if you’re having crashing, you want to adjust some of your parameters (like memory usage) so they’re not right on the edge of crashing, or run the backup at a lower peak time.

    There are lots of crashing bugs in older versions of MySQL, upgrading might fix your problems if you have version more than a few months old. Pythian has clients on Percona’s build of MySQL and the official MySQL builds, and we use both InnoDB Hot Backup and Xtrabackup on different clients, and we don’t find crashing.

    We did find similar usage for Xtrabackup vs. InnoDB hot backup – so Xtrabackup isn’t causing really different loads than InnoDB hot backup. (we found that xtrabackup consistently used 1% more resources, which isn’t that big of a deal, especially considering xtrabackup is free and Innodb Hot backup is very expensive) — the numbers are here: http://www.pythian.com/news/4177/taste-test-innobackup-vs-xtrabackup

    October 26, 2009 at 3:08 pm
  • Csfor October 29, 2009 at 2:14 am
  • gulf

    Does the xtrabackup support the partition table? For example, I just want to backup one partition.

    November 3, 2009 at 6:48 am
  • Mark Callaghan

    Xtrabackup and InnoDB hot backup do hot backups. A backup is hot when you can perform it on an active database. While there is a brief pause from the need to run FLUSH TABLES WITH READ LOCK (and that pause is to be eliminated in future versions of MySQL and forks) neither of these products require activity to be stopped.

    November 5, 2009 at 6:59 pm
  • Vadim


    We have added –no-lock option which allows to run xtrabackup without lock, and you can get binary log information from output, which is taken from InnoDB transactional log. It is safe to use if database is InnoDB-only

    November 5, 2009 at 7:47 pm
  • Mark Callaghan

    That is a very nice feature as I know several DBAs who really don’t like to run FLUSH TABLES WITH READ LOCK on a master.

    November 5, 2009 at 8:08 pm
  • r4i칩


    * Free
    * takes 1.1% longer (2 min during a 3 hour backup)
    * uses 1.4% more space (1G more in a 70G backup — this was for uncompressed backups)
    * uses 1.115% more cpu overall
    * split as 0.12% user, 0.66% nice, 0.025% system, 0.31% more iowait, 0% more steal

    November 15, 2009 at 10:26 pm
  • Nils

    Seems like there is no source tarball on the Server, only source rpm?

    November 26, 2009 at 12:33 am
  • khem

    agree with Nils 🙁

    February 7, 2010 at 1:24 am

Comments are closed.

Use Percona's Technical Forum to ask any follow-up questions on this blog topic.