Appendix A Frequently Asked Questions for MySQL Enterprise Backup — MySQL Enterprise Backup 8.4

Приложение А Часто задаваемые вопросы для MySQL Enterprise Backup

В этом разделе перечислены некоторые распространённые вопросы о MySQL Enterprise Backup, с ответами и ссылками на дополнительную информацию.

Вопросы

A.1: Какие версии сервера MySQL поддерживает MySQL Enterprise Backup 8.4.4?
A.2: Что представляет собой большой ibdata файл, присутствующий во всех резервных копиях?
A.3: Можно ли создать резервную копию данных, не являющихся InnoDB, с помощью MySQL Enterprise Backup?
A.4: Что произойдёт, если этап применения журнала (apply-log) или резервной копии (apply-incremental-backup) прервётся?
A.5: Почему опция --defaults-file не распознаётся?
A.6: Можно ли создать резервную копию сервера базы данных на одной операционной системе и восстановить её на другой с помощью MySQL Enterprise Backup?
A.7: Что делать, если в резервную копию включён бинарный журнал или журнал ретрансляции, но восстанавливать их не нужно?
A.8: Что произойдёт, если запустить сервер напрямую, используя резервную копию в виде сырой директории, не выполнив ни операцию копирования (copy-back), ни применение журнала (apply-log)?

Вопросы и ответы

A.1: Какие версии сервера MySQL поддерживает MySQL Enterprise Backup 8.4.4?

Подробности о совместимости между различными выпусками MySQL Enterprise Backup и MySQL Server см. в разделе C.3 «Совместимость с версиями MySQL».

A.2: Что представляет собой большой ibdata файл, присутствующий во всех резервных копиях?

Возможно, объём вашей резервной копии больше ожидаемого из-за большого файла с именем, подобным ibdata1. Этот файл представляет собой пространство таблиц InnoDB, которое увеличивается, но не уменьшается при работе сервера базы данных, и включается в каждую полную и инкрементную резервную копию. Для уменьшения занимаемого этим файлом места в резервной копии:

После выполнения полной резервной копии, выполните последовательность инкрементных резервных копий, занимающих меньшее место. Файл ibdata1 в инкрементных резервных копиях обычно гораздо меньше, содержа в себе только те части пространства таблиц системы, которые изменились с момента последней полной резервной копии.
Установите конфигурационную опцию перед созданием ваших самых больших или наиболее активных таблиц InnoDB. Эти таблицы отделяются от пространства таблиц системы в отдельные файлы .ibd; затем эти таблицы могут быть включены или исключены из резервных копий, а место на диске освобождается при удалении или усечении таблиц.
Если пространство таблиц системы очень велико из-за большого объёма данных InnoDB, созданного до активации настройки , вы можете использовать mysqldump для создания дампа всей вашей серверной инстанции, а затем активировать перед повторным созданием баз данных, чтобы все данные таблиц хранились вне пространства таблиц системы.

A.3: Можно ли создать резервную копию данных, не являющихся InnoDB, с помощью MySQL Enterprise Backup?

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

A.4: Что произойдёт, если этап применения журнала (apply-log) или резервной копии (apply-incremental-backup) прервётся?

Если mysqlbackup прервётся во время этапа apply-log или apply-incremental-backup, данные резервной копии будут в порядке. Операции с файлами, выполняемые этими опциями, могут быть выполнены несколько раз без ущерба для целостности данных резервной копии. Просто запустите ту же команду mysqlbackup снова, и когда она успешно завершится, все необходимые изменения будут присутствовать в данных резервной копии.

A.5: Почему опция --defaults-file не распознаётся?

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

A.6: Можно ли создать резервную копию сервера базы данных на одной операционной системе и восстановить её на другой с помощью MySQL Enterprise Backup?

Подробности см. в разделе C.2 «Совместимость между платформами».

A.7: Что делать, если в резервную копию включён бинарный журнал или журнал ретрансляции, но восстанавливать их не нужно?

Если вы хотите пропустить восстановление бинарного журнала, журнала ретрансляции или обоих во время восстановления, используйте опцию --skip-binlog, опцию --skip-relaylog или обе вместе с командой copy-back или copy-back-and-apply-log.

A.8: Что произойдёт, если запустить сервер напрямую, используя резервную копию в виде сырой директории, не выполнив ни операцию копирования (copy-back), ни применение журнала (apply-log)?

Этого делать не следует. Сервер не только может упасть, но и резервная копия, скорее всего, будет повреждена и станет непригодной для использования. Это связано с тем, что резервная копия каталога содержит метаданные, созданные mysqlbackup, которые сервер MySQL не сможет понять; также сырая резервная копия может быть несогласованной и потребовать обновления с помощью операции применения журнала, чтобы можно было применить изменения, внесённые в сервер базы данных во время процесса резервного копирования.