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

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

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

Вопросы

A.1: Какие версии сервера MySQL поддерживает MySQL Enterprise Backup 4.1?
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 4.1?

Подробную информацию о совместимости между различными версиями 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 не будет понимать; кроме того, сырая резервная копия может быть несогласованной и нуждается в обновлении с помощью операции apply-log, чтобы применить изменения, внесенные в базу данных во время процесса резервного копирования.