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

Столбец 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, которые оба применяют минимальную блокировку таблиц.

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

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

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

mysql> ALTER TABLE mytable ENGINE = INNODB;

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

mysql> CHECK TABLE mytable;
 

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

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

Во время процесса резервного копирования, если операция CREATE INDEX с ALGORITHM = INPLACE выполняется во время резервного копирования, так как операция не записывается в журнал переигрывания сервера MySQL (см. для получения подробностей), она не может быть включена в резервную копию, и индекс не будет пересоздан командой 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 применяются некоторые ограничения. Подробности см. в соответствующей статье.

Операции резервного копирования завершаются неудачно, если сервер был запущен с =ON

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

Безопасно выполнять DDL-операции (, , , , и операции, отображающие в ) на сервере параллельно с операцией резервного копирования, если:

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

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

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