Movatterモバイル変換

In some cases, backups of non-transactional tables such asMyISAM tables could contain additional uncommitted data. Ifautocommit is turned off, and bothInnoDB 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.

Theengines column in themysql.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. SeeSection 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 usingtransportable 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 usingtransportable tablespace (TTS) would fail when any (or all) of its partitions were created in a shared tablespace.

Restoring a partitioned table backed up usingtransportable tablespace (TTS) would fail if any of the partitions was created outside of the backed-up server's data directory.

If a table containing full-text search (FTS) index is backed up usingtransportable 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 theANSI_QUOTES SQL mode cannot be backed up usingtransportable 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.

During a backup process, if aCREATE INDEX statement withALGORITHM = INPLACE is issued when the backup process is going on, because the statement will not go into the redo log of the MySQL server (seeSorted Index Builds for details), it cannot be recorded in the backup, and the index will not be recreated bymysqlbackup 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 bymysqlbackup unless the--only-known-file-types option is used. However, if the name of the file does not have an extension, it will causemysqlbackup to throw an error when it tries to restore the backup to a server.

Cloud operations by MySQL Enterprise Backup are not supported on macOS or 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 theextract command on cloud backups will cause the command to fail. Cloud backups can only be extracted in full.

Some limitations apply whenmysqlbackup works withencrypted InnoDB tables. Seethe discussion here for details.

Backup operations may fail if checksums for redo log pages are disabled (i.e., if--innodb_log_checksums isOFF orFALSE or0) on the server.

For MySQL Enterprise Backup 8.0.19 and later: It is safe to have DDL operations (CREATE TABLE,RENAME TABLE,DROP TABLE,ALTER TABLE, and operations that map toALTER TABLE likeCREATE INDEX) happening on the server in parallel with a backup operation as long as:

A compressed directory backup fails when a general tablespace bears the same basename as the database server's system tablespace (usuallyibdata1) 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 server.

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 theid values generated by the source and the replica, causing backups to fail.

A backup fails if the name of any database is the same as the name of any undo tablespace. For backups to be successful, the database administrator should avoid giving any database and undo tablespace the same name (for example, using the default undo tablespace nameundo_001 to name a database), or the database should be renamed before a backup.