Documentation Home
MySQL Enterprise Backup 3.12 User's Guide
Related Documentation Download this Manual
PDF (US Ltr) - 1.1Mb
PDF (A4) - 1.1Mb
HTML Download (TGZ) - 174.2Kb
HTML Download (Zip) - 199.7Kb


MySQL Enterprise Backup 3.12 User's Guide  /  Appendixes  /  Limitations of MySQL Enterprise Backup

Appendix B Limitations of MySQL Enterprise Backup

Please refer to the MySQL Enterprise Backup version history in Appendix D, MySQL Enterprise Backup Release Notes for a list of fixed mysqlbackup bugs. Here are a list of limitaions of MySQL Enterprise Backup:

  • The group commit feature in MySQL 5.6 and higher changes the frequency of flush operations for the InnoDB redo log, which could affect the point in time associated with the backup data from InnoDB tables. See Section C.4, “Compatibility Notes for Specific MySQL Versions” for details.

  • In Linux, Unix, and OS X systems, mysqlbackup does not record file ownership or permissions of the files that are backed up. Upon restore, these files might have different ownership (for example, being owned by root now rather than mysql). They might also have different read/write permissions (for example, being readable by anyone rather than just the file owner). When planning your backup strategy, survey the files in the MySQL data directory to ensure they have consistent owner and permission settings. When executing a restore operation, use an appropriate combination of su, umask, chown, and chmod on the restored files to set up the same owners and privileges as on the original files. The simplest way to ensure correct file ownership and permissions is to run the restore operation as the same user who runs the server, typically mysql.

  • In some cases, backups of non-transactional tables such as MyISAM tables could contain additional uncommitted data. If autocommit is turned off, and both InnoDB tables and non-transactional tables are modified within the same transaction, data can be written to the non-transactional table before the binary log position is updated. The binary log position is updated when the transaction is committed, but the non-transactional data is written immediately. If the backup occurs while such a transaction is open, the backup data contains the updates made to the non-transactional table.

  • If the mysqlbackup process is interrupted by, for example, a Unix kill -9 command, a FLUSH TABLES WITH READ LOCK operation might remain running. In this case, use the KILL QUERY statement from the mysql command line to kill the FLUSH TABLES WITH READ LOCK statement. This issue is more likely to occur if the FLUSH TABLES operation is stalled by a long-running query or transaction. Refer to Section 7.1, “Optimizing Backup Performance” for guidelines about backup timing and performance.

  • Do not run the DDL operations (for example, ALTER TABLE, TRUNCATE TABLE, OPTIMIZE TABLE, REPAIR TABLE, RESTORE TABLE or CREATE INDEX) while a backup operation is going on. The resulting backup might become corrupted.

  • The engines column in the mysql.backup_history table does not correctly reflect the storage engines of the backed-up databases.

  • Hot backups for large databases with heavy writing workloads (say, in the order of gigabytes per minute) can take a very long time to complete, due to the huge redo log files that are generated on the server when the backup is in progress. And if the redo log files grow faster than they can be processed by mysqlbackup, the backup operation can actually fail when mysqlbackup cannot catch up with the redo log cycles and LSNs get overwritten by the server before they are read by mysqlbackup. The problem is intensified when the I/O resources available for reading and writing the redo logs are scarce during the backup process. However, if only a small number of tables of the database are modified frequently, the Optimistic Backup feature might alleviate the problem. See Section 4.3.6, “Making an Optimistic Backup” for details.

  • Compressed InnoDB tables from MySQL server 5.6.10 and earlier cannot be restored with MySQL Enterprise Backup 3.9.0 or later, due to a known issue with the InnoDB storage engine (see Bug# 72851 on the MySQL Bug System).

  • While it is possible to backup to or restore from a Network Attached Storage (NAS) device using MySQL Enterprise Backup, due to networking issues that might arise, the consistency of the backups and the performance of the backup or restore operations might be compromised.

  • When creating a backup using transportable tablespace (TTS) for a server containing tables with a mix of the Antelope and Barracuda file formats, do not apply full locking on the tables (that is, do not specify --use-tts=with-full-locking). Instead, just specify --use-tts or --use-tts=with-minimum-locking, both of which will apply minimum locking to the tables (Bug #20583946).

  • Tables created on the MySQL server with the ANSI_QUOTES SQL mode cannot be backed up using transportable tablespace (TTS).

  • When a file of an unrecognized file type exists under a subdirectory in the server's data directory, it will be backed up by mysqlbackup unless the --only-known-file-types option is used. However, if the name of the file does not have an extension, it will cause mysqlbackup to throw an error when it tries to restore the backup to a server.

  • If a table on the server is dropped while mysqlbackup is backing up that table, mysqlbackup throws an error and exits.

  • Offline backups using MySQL Enterprise Backup 3.12.2 sometimes fail, with occasional crashes of mysqlbackup.

  • Using the --src-entry option with the extract command on cloud backups will cause the command to fail. Cloud backups can only be extracted in full.

  • Due to some issues, cloud backup and restore using Amazon S3 is currently not supported by MySQL Enterprise Backup 3.12.


User Comments
User comments in this section are, as the name implies, provided by MySQL users. The MySQL documentation team is not responsible for, nor do they endorse, any of the information provided here.
Sign Up Login You must be logged in to post a comment.