Вопросы и ответы
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, чтобы могли быть применены изменения, внесенные в базу данных во время процесса резервного копирования.