В некоторых случаях резервные копии не транзакционных таблиц, таких как таблицы, могут содержать дополнительные незавершенные данные. Если выключено, и как таблицы, так и не транзакционные таблицы изменяются в рамках одной транзакции, данные могут быть записаны в не транзакционную таблицу до обновления позиции бинарного журнала. Позиция бинарного журнала обновляется при подтверждении транзакции, но данные не транзакционной таблицы записываются немедленно. Если резервное копирование происходит во время открытия такой транзакции, данные резервной копии содержат обновления, внесенные в не транзакционную таблицу.

Если процесс mysqlbackup прерывается, например, командой Unix kill -9, операция FLUSH TABLES WITH READ LOCK может оставаться активной. В этом случае используйте оператор KILL QUERY из командной строки mysql для завершения оператора FLUSH TABLES WITH READ LOCK. Эта проблема чаще возникает, если операция FLUSH TABLES заблокирована длительным запросом или транзакцией. Обратитесь к Разделу 11.1, «Оптимизация производительности резервного копирования» за рекомендациями по времени резервного копирования и производительности.

Не выполняйте операции DDL (например, ALTER TABLE, TRUNCATE TABLE, OPTIMIZE TABLE, REPAIR TABLE, RESTORE TABLE или CREATE INDEX) во время операции резервного копирования. Результатом может стать повреждение резервной копии.

Столбец engines в таблице mysql.backup_history некорректно отражает движки хранения резервируемых баз данных.

Горячие резервные копии больших баз данных с интенсивной записью (скажем, в порядке гигабайтов в минуту) могут занимать очень много времени из-за больших файлов журнала восстановления, которые генерируются на сервере во время резервного копирования. Однако, если часто изменяется относительно небольшой набор таблиц в базе данных, можно использовать функцию оптимистического резервного копирования для повышения производительности и уменьшения размера резервной копии, а также времени резервного копирования и восстановления. Подробности см. в Разделе 4.3.6, «Создание оптимистической резервной копии».

Хотя резервное копирование на устройство сетевого хранения (NAS) с помощью MySQL Enterprise Backup возможно, из-за проблем с сетью может быть нарушена согласованность резервных копий и производительность операций резервного копирования или восстановления.

При создании резервной копии с использованием для сервера, содержащего таблицы с сочетанием форматов файлов Antelope и Barracuda, не применяйте полную блокировку таблиц (т. е. не указывайте --use-tts=with-full-locking). Вместо этого укажите --use-tts или --use-tts=with-minimum-locking, которые применяют минимальную блокировку к таблицам.

Резервное копирование разграниченной таблицы с использованием не удастся, если хотя бы одна (или все) ее секции были созданы в общем хранилище таблиц.

Восстановление разграниченной таблицы, резервную копию которой создавали с помощью , даже при использовании опции --force, не удастся, если хотя бы одна секция была создана вне каталога данных сервера резервной копии.

Если в процессе создания резервной копии с помощью на сервере выполняются операторы Data Definition Language (DDL), резервное копирование может завершиться ошибкой. Это происходит потому, что таблицы, не включенные в резервное копирование, не блокируются в процессе резервного копирования, но mysqlbackup все равно проверяет состояние этих таблиц в конце процесса, и может возникнуть ошибка, если определения этих таблиц были изменены. Чтобы избежать этой проблемы, не выполняйте никаких операций DDL, особенно DROP TABLE, когда выполняется резервное копирование TTS.

Если таблица, содержащая индекс полнотекстового поиска (FTS), резервируется с помощью , после восстановления индекс FTS будет поврежден. Пользователям потребуется пересоздать индекс с помощью следующей команды:

mysql> ALTER TABLE mytable ENGINE = INNODB;

Затем проверьте, что в таблице больше нет ошибок:

mysql> CHECK TABLE mytable;
 

Таблицы, созданные на сервере MySQL с режимом SQL не могут быть резервированы с помощью .

MySQL Enterprise Backup не включает в резервную копию файлы .pem с сервера. Эти файлы являются частью экземпляра сервера при включении SSL-соединений.

При резервном копировании экземпляра MySQL 5.7, если оператор CREATE INDEX с ALGORITHM = INPLACE выполняется во время процесса резервного копирования, поскольку оператор не войдет в журнал восстановления сервера MySQL 5.7 (см. для получения подробностей), он не может быть записан в резервную копию, и индекс не будет пересоздан mysqlbackup при восстановлении резервной копии.

Если в подкаталоге каталога данных сервера существует файл с неизвестным типом файла, он будет резервироваться mysqlbackup, если не используется опция --only-known-file-types. Однако, если у файла нет расширения, это вызовет ошибку mysqlbackup при попытке восстановить резервную копию на сервер.

Облачные операции MySQL Enterprise Backup не поддерживаются на платформах macOS и Windows, а также на платформах Linux, когда используются общие сборки Linux как для сервера, так и для MySQL Enterprise Backup (т. е. когда и сервер, и MySQL Enterprise Backup установлены с помощью общих пакетов Linux tar).

Использование опции --src-entry с командой extract для облачных резервных копий приведет к ошибке. Облачные резервные копии могут быть извлечены только полностью.

При работе mysqlbackup с зашифрованными таблицами InnoDB существуют ограничения. Подробнее см. в обсуждении здесь.

Операции резервного копирования могут завершиться ошибкой, если контрольные суммы страниц журнала восстановления отключены (т. е., если OFF или FALSE или 0) на сервере.

Резервная копия сжатого каталога завершается ошибкой, когда общее хранилище таблиц имеет то же базовое имя, что и системное хранилище таблиц базы данных (обычно ibdata1) и существует в том же каталоге (обычно каталог данных сервера). Сжатая резервная копия одного файла, созданная в такой ситуации, будет повреждена и не сможет быть восстановлена. Чтобы избежать этой проблемы, администратор сервера не должен размещать системное хранилище таблиц и общее хранилище таблиц с одинаковым базовым именем в одном каталоге; если это неизбежно, не выполняйте сжатое резервное копирование для базы данных.

При работе с конфигурацией репликации, где исходный сервер также принадлежит к отдельной конфигурации Group Replication, со временем создавайте резервные копии последовательно либо с исходного, либо с реплики, но не с обоих. В противном случае возникнут конфликты между значениями id, сгенерированными исходным и репликой, что приведет к ошибкам резервного копирования.

Резервное копирование завершается ошибкой, если имя любой базы данных совпадает с именем любого хранилища отмены. Для успешного резервного копирования администратор базы данных должен избегать присвоения одинаковых имен базам данных и хранилищам отмены (например, используя имя по умолчанию для хранилища отмены undo_001 для именования базы данных) или база данных должна быть переименована перед резервным копированием.

База данных, содержащая таблицы и удаленная незадолго до начала резервного копирования, отображается как пустая база данных при восстановлении резервной копии. Удаленную базу данных необходимо удалить вручную с восстановленного сервера.