MySQL Enterprise Backup User's Guide (Version 3.12.5)
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.5, “Compatibility Notes for Specific MySQL Versions” for details.
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 while the backup is running. However, when it is a relatively small subset of tables in the database that are being modified frequently, the Optimistic Backup feature can be used to improve performance and reduce backup size, as well as backup and recovery times. 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.
Cloud operations by MySQL Enterprise Backup are not supported on macOS and Windows platforms, and also on Linux platforms when generic Linux builds are used for both the server and MySQL Enterprise Backup (i.e., when both the server and MySQL Enterprise Backup have been installed using generic Linux tarballs).
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.
A compressed directory backup fails when a general tablespace
bears the same basename as the database's system tablespace
(usually ibdata1
) and exists in the same
directory with it (usually the server's data directory). A
compressed single-file backup created under the same situation
will be corrupted, and cannot be restored. To avoid the problem,
the server administrator should not put into the same directory
the system tablespace and a general tablespace of the same
basename; if that is unavoidable, do not perform a compressed
backup for the database.
When working with a replication set up whose source server also
belongs to a separate Group Replication setup, over time, create
backups consistently either from the source or the replica, but
not from both. Otherwise, there will be conflicts between the
id
values generated by the source and the
replica, causing backups to fail.