August 22, 2014

Percona XtraBackup 1.6.3

Percona is glad to announce the release of Percona XtraBackup 1.6.3 on 22 September, 2011 (Downloads are available here and from the Percona Software Repositories).

This release is purely composed of bug fixes and is the current stable release of Percona Xtrabackup.

If the innodb_file_per_table server option is being used and DDL operations, TRUNCATE TABLEDROP/CREATE the_same_table or ALTER statements on InnoDB tables are executed while taking a backup, an upgrade to XtraBackup 1.6.3 is strongly recommended. Under this scenario, if the server version is prior to 5.5.11 in 5.5 series or prior to 5.1.49 in 5.1 series, a server upgrade is also recommended.

All of Percona’s software is open-source and free, all the details of the release and its development process can be found in the 1.6.3 milestone at Launchpad.

Bugs Fixed

  • Streaming backups did not work for compressed InnoDB tables due to missing support for compressed pages in tar4ibd. Bug Fixed: #665210 (Alexey Kopytov).
  • XtraBackup failed when innodb_flush_method in the server configuration file was set to ALL_O_DIRECT. Bug Fixed: #759225 (Alexey Kopytov).
  • Due to a regression introduced in XtraBackup 1.6.2, innobackupex --copy-back did not work if the xtrabackup binary was not specified explicitly with the --ibbackupoption. Bug Fixed: #817132 (Alexey Kopytov).
  • The --slave-info option now works correctly with --safe-slave-backup when either --no-lock or --incremental is also specified. Bug Fixed: #834657 (Alexey Kopytov).
  • tar4ibd could fail with an error when processing doublewrite pages. Bug Fixed: #810269 (Alexey Kopytov).
  • Unsupported command line options could cause a tar4ibd crash. Such options have been removed. Bug Fixed: #677279 (Alexey Kopytov).
  • Executing DDL operations, TRUNCATE TABLEDROP/CREATE the_same_table or ALTER statements on InnoDB tables while taking a backup could lead to a xtrabackup failure due to a tablespace ID mismatch when using per-table tablespaces. Note that this fix may not work correctly with MySQL 5.5 or Percona Server 5.5 prior to version 5.5.11. 5.1 releases from 5.1.49 or higher have been confirmed not to be affected. If the innodb_file_per_table option is being used, an upgrade to XtraBackup 1.6.3 isstrongly recommended. Under this scenario, if the server version is prior to 5.5.11 in 5.5 series or prior to 5.1.49 in 5.1 series, a server upgrade is alsorecommended. Bug Fixed: #722638 (Alexey Kopytov).

Other Changes

  • Improvements and fixes on the XtraBackup Test Suite: #855035#787966 (Alexey Kopytov)

More Information

For more information, please see the following links:

Comments

  1. honeybee says:

    can xtrabackup or innobackupex restore partial database, such as a schema or a table from a full backup?

  2. Alexey Kopytov says:

    honeybee,

    It is possible to restore individual tables created in the innodb_file_per_table_mode using the export functionality of XtraBackup (and XtraDB’s innodb_expand_import feature): http://www.percona.com/docs/wiki/percona-xtrabackup:xtrabackup:export_and_import

  3. honeybee:
    I hope so, it can not currently be,if can do this,it recovery be quickly.

  4. honeybee says:

    @Alexey:
    I have also looked in the export/import utility, but the source of import is a per table export, not full database backup. If I do per table export as full backup method, the full backup will not be consistent as different tables was backed up at different time and I will have problem to do full database recovery. If have a consistent xtrabackup (backup + apply log) then I have to recover the whole database in order to restore one table.

  5. honeybee says:

    @Alexey:
    Sorry, I misunderstood the document, I just did a test on exporting table from full backup, and it works like a charm, thanks a lot!!!

Speak Your Mind

*