There is a number of Percona XtraBackup related issues with compressed InnoDB tables. These issues result from either server-side bugs, or OS configuration and thus, cannot be fixed on the Percona XtraBackup side.
- For MySQL or Percona Server versions 5.1 and 5.5 there are known and unfixed bugs with redo-logging of updates to compressed InnoDB tables. For example, internal Oracle bug #16267120 has been fixed only in MySQL 5.6.12, but not in 5.1 or 5.5. The bug is about compressed page images not being logged on page reorganization and thus, creating a possibility for recovery process to fail in case a different zlib version is being used when replaying a
MLOG_ZIP_PAGE_REORGANIZEredo log record.
- For MySQL or Percona Server version 5.6 it is NOT recommended to set
innodb_log_compressed_pages=OFFfor servers that use compressed InnoDB tables which are backed up with Percona XtraBackup. This option makes InnoDB recovery (and thus, backup prepare) sensible to
zlibversions. In case the host where a backup prepare is performed uses a different
zlibversion than the one that was used by the server during runtime, backup prepare may fail due to differences in compression algorithms.
- Backed-up table data could not be recovered if backup was taken while running
OPTIMIZE TABLE(bug #1541763) or
ALTER TABLE ... TABLESPACE(bug #1532878) on that table.
- Compact Backups currently don’t work due to bug #1192834.
- Backup fails with
Error 24: 'Too many open files'. This usually happens when database being backed up contains large amount of files and Percona XtraBackup can’t open all of them to create a successful backup. In order to avoid this error the operating system should be configured appropriately so that Percona XtraBackup can open all its files. On Linux, this can be done with the
ulimitcommand for specific backup session or by editing the
/etc/security/limits.confto change it globally (NOTE: the maximum possible value that can be set up is
1048576which is a hard-coded constant in the Linux kernel).
xtrabackup binary has some limitations you should be aware of to ensure
that your backups go smoothly and are recoverable.
- The Aria storage engine is part of MariaDB and has been integrated in it for many years and Aria table files backup support has been added to innobackupex in 2011. The issue is that the engine uses recovery log files and an
aria_log_controlfile that are not backed up by xtrabackup. As stated in the documentation, starting MariaDB without the
maria_log_controlfile will mark all the Aria tables as corrupted with this error when doing a
CHECKon the table:
Table is from another system and must be zerofilled or repaired to be usable on this system. This means that the Aria tables from an xtrabackup backup must be repaired before being usable (this could be quite long depending on the size of the table). Another option is
aria_chk --zerofil tableon all Aria tables present on the backup after the prepare phase.
- If the
xtrabackup_logfileis larger than 4GB, the
--preparestep will fail on 32-bit versions of
xtrabackupdoesn’t understand the very old
my.cnfsyntax that MySQL uses. See Configuring xtrabackup.
For general inquiries, please send us your question and someone will contact you.