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 B.3, “Compatibility Notes for MySQL Versions” for details.
For MySQL 5.5 and earlier, when restoring an individual InnoDB table, as described in Section 4.4, “Backing Up and Restoring a Single .ibd File”, the table must not have been dropped or truncated in the MySQL server after the backup. Dropping or truncating an InnoDB table changes its internal table ID, and when the table is re-created the ID will not match the table ID from the backup data. This restriction does not apply to MySQL 5.6 and later, as long as the restoration is made from one Generally Available (GA) version to another in the same series of MySQL servers.
In Linux, Unix, and OS X systems, the
mysqlbackup command 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 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
chmod on the restored files to set up the
same owners and privileges as on the original files.
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,
such as by a Unix
kill -9 command, a
FLUSH TABLES WITH READ LOCK operation might
remain running. In this case, use the
QUERY statement from the mysql
command line to kill the
FLUSH TABLES WITH READ
LOCK statement. This issue is more likely to occur
FLUSH TABLES operation is stalled by
a long-running query or transaction. Refer to
Chapter 5, mysqlbackup Command Reference for guidelines about backup
timing and performance.
Do not run the DDL operations
REPAIR TABLE, or
RESTORE TABLE while a backup operation is
going on. The resulting backup might be corrupted.
ALTER TABLE operations that can be
safely run in parallel with a backup are those that do not
influence the physical representation of records on disk, such
as changing column names or default column values.
The maximum number of subdirectories allowed in the
--backup-dir path is 21. This limit could be
exceeded by a deeply nested backup directory, or by an
anomalous condition such as symbolic links forming an infinite
binary log format is used on the MySQL server (which is
the default behavior), if you take a backup when there are
temporary tables in the database and you use those temporary
tables to update or insert into normal tables, application of
the MySQL binlog to a backup could then fail—that is,
you might not be able to roll forward the backup to a
particular point in time using the MySQL binlog. This is
because temporary tables are not copied to the backup, as the
#sql*.frm do not
correspond to the logical table names that MySQL writes to the
binlog. To avoid the problem, use row-based or mixed format
for the binary log by setting the value for the
--binlog-format option to
“ROW” or “MIXED” on the server.
engines column in the
mysql.backup_history table does not
correctly reflect the storage engines of the backed-up
When saving any tables into the data directory, the MySQL server performs conversions for any special characters in any database or table names to come up with the file names for storage. Here are two examples of MySQL commands including special characters (“.” and “-”) in their database and file names:
CREATE TABLE `db.2`.`t.2` (c1 INT) ENGINE=InnoDB;mysql>
CREATE TABLE `db-3`.`t-3` (c1 INT) ENGINE=InnoDB;
The tables created by these commands are stored in the file system as these files:
Currently, mysqlbackup does not perform the
same conversion with database and table names supplied using
Using, for example,
will no not select the tables described above.
As a workaround, for a backup that does not use
tablespace (TTS) (that is, the
--use-tts option is not used
during the creation of the backup), users can look up the file
names for the desired tables in the data directories of the
databases and, in the arguments for the
--exclude-tables options, use the
converted names for the database directories as database names
and the converted file names (without the file extension) as
table names . For example, for the tables mentioned above,
select them for inclusion in a backup with the option argument
Using the same argument with the option
--exclude-tables excludes the two
tables in the backup.
However, the suggested workaround does not work for TTS backups; therefore, do not use TTS if you want to do a partial backup that includes tables with special characters in their names.
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 bug 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.