MySQL Enterprise Backup User's Guide (Version 4.0.3)
Please refer to the MySQL Enterprise Backup 4.0 Release Notes for a list of fixed bugs for mysqlbackup. Here is a list of limitations of MySQL Enterprise Backup:
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 10.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.
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.
Backup of a partitioned table using transportable tablespace (TTS) would fail when any (or all) of its partitions were created in a shared tablespace.
Restoring a partitioned table backed up using
transportable
tablespace (TTS), even when the
--force
option is used, would fail
if any of the partitions was created outside of the backed-up
server's data directory.
If Data Definition Language (DDL) statements are executed on the
server when a backup is being created using
transportable
tablespace (TTS), the backup might fail. It is because
tables not being backed up are not locked during the backup
process, but mysqlbackup still checks the
status of those tables at the end of the process, and an error
might occur if definitions of those tables have been changed. To
avoid the problem, do not perform any DDL operation, especially
DROP TABLE
, when a TTS backup is going on.
If a table containing full-text search (FTS) index is backed up using transportable tablespace (TTS), after it is restored, the FTS index will be corrupted. Users will need to recreate the index with the following command:
mysql> ALTER TABLE mytable ENGINE = INNODB;
Then, check that there are no more errors with the table:
mysql> CHECK TABLE mytable;
Tables created on the MySQL server with the
ANSI_QUOTES
SQL mode cannot be
backed up using
transportable
tablespace (TTS).
MySQL Enterprise Backup does not include the .pem
files from
the server into the backup. The files are part of the server
instance when SSL connections are enabled.
When using the backup-and-apply-log
command without a connection to the MySQL server,
mysqlbackup cannot know the correct binary
log file name and binary log position for the backup; yet, at
the end of the backup-and-apply-log
operation, mysqlbackup still prints out some
values for the binary log file name and position, which are
random in nature and should be ignored by users.
When backing up an instance of MySQL 5.7, if a CREATE
INDEX
statement with ALGORITHM =
INPLACE
is issued when the backup process is going on,
because the statement will not go into the redo log of the MySQL
5.7 server (see
Sorted Index Builds for details),
it cannot be recorded in the backup, and the index will not be
recreated by mysqlbackup when the backup is
restored.
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.
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.
Some limitations apply when mysqlbackup works with encrypted InnoDB tables. See the discussion here for details.
Due to some issues, cloud backup and restore using Amazon S3 is currently not supported by MySQL Enterprise Backup 4.0.