RussianLDP Рейтинг@Mail.ru
WebMoney: 
WMZ Z294115950220 
WMR R409981405661 
WME E134003968233 
Visa 
4274 3200 2453 6495 

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

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

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

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

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

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

  • После выполнения полного резервного копирования сделайте последовательность возрастающих резервных копий , которые занимают меньше места. Файл ibdata1 в возрастающих резервных копиях типично намного меньше, так как содержит только части системного табличного пространства, которое изменилось, начиная с полного резервного копирования.

  • Установите параметр конфигурации innodb_file_per_table=1 прежде, чем составить ваши самые большие или самые активные таблицы InnoDB. Они будут отделены от системных табличных пространств в отдельные файлы .ibd, таблицы тогда могут быть индивидуально включены или исключены из резервных копий, дисковое пространство освобождено, когда таблицы пропущены или усечены.

  • Если ваше системное табличное пространство очень большое, потому что вы создали большой объем данных InnoDB перед включением innodb_file_per_table, вы могли бы использовать mysqldump, чтобы создать дамп всего сервера, затем включить innodb_file_per_table прежде, чем воссоздать базу данных, чтобы все данные таблиц были сохранены вне системного табличного пространства.

A.3: Я могу поддержать не-InnoDB данные с MySQL Enterprise Backup?

MySQL Enterprise Backup может поддержать данные не-InnoDB (например, таблицы MYISAM), но сервер MySQL который будет зарезервирован, должен поддерживать InnoDB (то есть, процесс резервного копирования потерпит неудачу, если сервер был запущен с опцией --innodb=OFF или --skip-innodb, при этом сервер должен содержать по крайней мере одну таблицу InnoDB.

A.4: Что происходит, если шаг apply-log или apply-incremental-backup прерван?

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

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

Когда вы определяете --defaults-file, это должно быть первой опцией после mysqlbackup. Иначе будет сообщение об ошибке, как будто имя опции не признано.

A.6: Я могу поддержать базу данных на одной платформе OS и восстановить ее на другой с использование 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, чтобы могли быть применены изменения, внесенные в базу данных во время процесса резервного копирования.

Поиск

 

Найди своих коллег!

Вы можете направить письмо администратору этой странички, Алексею Паутову. mailto:alexey.v.pautov@mail.ru