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

Глава 1. Введение в MySQL Enterprise Backup

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

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

MySQL Enterprise Backup это ценный инструмент для поддержания и охраны ваших данных MySQL, для быстрого и надежного восстановления, когда несчастные случаи или бедствия происходят. Это часть MySQL Enterprise Edition, доступного подписчикам в соответствии с коммерческой лицензией.

Среди прочего это руководство объясняет:

  • Как установить MySQL Enterprise Backup.

  • Различные виды резервных копий, которые могут быть выполнены с MySQL Enterprise Backup, как выполнить их и некоторые подсказки при выборе правильного вида резервных копий для вашей системы.

  • Как восстановить резервные копии, созданные MySQL Enterprise Backup.

  • Как использовать MySQL Enterprise Backup в специальных ситуациях или для особых целей (например, настраивая репликацию, используя продукты Media Management Software (MMS) или Distributed File System (DFS)).

  • Клиент mysqlbackup, его команды и варианты команд.

1.1. Клиент mysqlbackup

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

Использование клиента mysqlbackup и связанных команд объяснено и иллюстрировано всюду в этом руководстве. Для получения дальнейшей информации по командам mysqlbackup и вариантам команд, посмотрите часть III.

1.2. Обзор типов резервирования

Когда дело доходит до формулировки вашей стратегии резервного копирования работа и место в памяти это ключевые соображения. Вы хотите, чтобы резервная копия закончилась быстро с как можно меньшей нагрузкой на CPU на сервере базы данных. Вы также хотите, чтобы данные резервного копирования были компактны, таким образом, можно держать многочисленные резервные копии под рукой, чтобы восстановить в любой момент. Передача данных резервного копирования к иной системе должна быть быстрой и удобной. На таких соображениях различные стратегии поддержки вашей базы данных часто дают вам различные преимущества различных компромиссов, которые вы делаете, выбирая конкретную стратегию. Чтобы выбрать стратегию, необходимо понять природу каждого вида резервных копий, которые может выполнить MySQL Enterprise Backup, поэтому эта секция дает краткий обзор.

Виды резервных копий согласно разрушению уровня обслуживания

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

  • Очень мало нарушает работу: горячее резервное копирование это резервная копия, выполненная в то время, как база данных работает. Этот тип резервных копий не блокирует нормальные операции по базе данных. Это захватывает даже изменения, которые происходят в то время, как резервная копия происходит. По сравнению с другими типами резервирования это вызывает наименьшее количество проблем с сервером базы данных и это желательный выбор, когда вы хотите избежать проблем с прекращением работы сервиса. Однако, прежде чем горячее резервное копирование может быть восстановлено, должен быть дополнительный процесс подготовки резервной копии, чтобы сделать ее последовательной (то есть правильно отражающей состояние базы данных в то время, когда резервная копия была закончена). Посмотрите раздел 5.1.7.

    Когда связано с работающим сервером MySQL, MySQL Enterprise Backup выполняет горячее резервное копирование для таблиц InnoDB.

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

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

  • Полное отключение сервиса: холодное резервное копирование это резервная копия, созданная, в то время как база данных остановлена. Это очень сильно вмешивается в работу базы данных. MySQL Enterprise Backup 8.0 не поддерживает холодное резервное копирование .

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

Согласно тому, хотите ли вы включать все данные в свою резервную копию или только недавние изменения, можно выполнить полное резервное копирование, дифференциальное резервное копирование или инкрементное резервное копирование. У трех типов резервных копий есть разные уровни требований для CPU и дискового пространства, таким образом они подходят для различных ситуаций:

  • Полное резервное копирование включает полные данные из базы данных (кроме случаев, где некоторые таблицы исключены частичными резервными вариантами).

  • Дифференциальное резервное копирование включает все изменения данных начиная с последнего полного резервного копирования. Это быстрее, чем полное резервное копирование, экономит память на сервере базы данных и экономит на сетевом трафике, когда резервная копия передается иному серверу. Однако, это требует дополнительной обработки, чтобы сделать резервную копию готовой к восстановлению, которую можно выполнить на иной системе, чтобы минимизировать издержки CPU на сервере базы данных.

  • Инкрементное резервное копирование включает все изменения данных, начиная с последней резервной копии. Это предлагает преимущества перед полным резервным копированием, подобные тем, какие делает дифференциальное резервное копирование, и часто до еще большей степени уменьшение размера резервных копий. Но могло бы также требоваться больше приготовлений на более длинном ряде резервных копий, прежде чем восстановление сможет быть выполнено.

Сжатые резервные копии против несжатых

Резервное сжатие экономит вам пространство памяти и сетевой трафик, чтобы передать данные резервного копирования на иной сервер. Сжатие действительно добавляет некоторые издержки CPU, но это зависит от алгоритма, и это довольно низко для алгоритма по умолчанию, используемого MySQL Enterprise Backup. Кроме того, сжатие часто уменьшает издержки IO, что могло бы сократить время восстановления специально для медленных устройств IO. Однако, во время восстановления вам потребуется время для декомпрессии, а также пространство памяти для обоих, сжатых и развернутых, данных в то же время. Так что примите во внимание дополнительное пространство памяти и дополнительное время, необходимое во время восстановления, рассматривая, создать ли сжатые резервные копии.

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

Для подробностей о методах и компромиссах, включающих резервную копию и восстановление см. раздел 13.

1.3. Файлы, которые поддерживаются

Эта секция объясняет различные типы файлов, содержащиеся в резервной копии.

1.3.1. Типы файлов, содержащиеся в резервной копии

Следующая таблица показывает различные типы файлов, которые включены в образ однофайлового резервного копирования или директивную резервную копию. В случае однофайлового резервного копирования распакуйте файл в резервную структуру каталогов , используя команду extract или image-to-backup-dir, чтобы рассмотреть файлы.

Таблица 1.1. Типы файлов в резервной копии

Имя файла, образец или расширение

Отношение к оригинальным файлам данных

Примечания

ibdata*

Системное табличное пространство InnoDB, содержащее таблицы InnoDB и связанные индексы.

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

*.ibd

Табличное пространство InnoDB, которое может быть (a) табличным пространством file-per-table, содержащим единственную таблицу InnoDB и связанные индексы, или (b) файл для таблицы внешнего табличного пространства, расположенное за пределами каталога данных сервера, содержащего единственную таблицу InnoDB, или (c) общим табличным пространством, содержащим одну или несколько таблиц и их индексы.

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

*.ibz

Сжатая форма файлов данных InnoDB из каталога данных MySQL.

Произведен вместо файлов .ibd в сжатой резервной копии. Файлы ibdata*, представляющие системное табличное пространство InnoDB, также получают это расширение в сжатой резервной копии.

Файлы .ibz разсжаты во время шагов apply-log, copy-back или copy-back-and-apply-log.

*.sdi

Хранит Serialized Dictionary Information (SDI) таблиц MyISAM, которая является метаданными таблиц.

База данных помещается в статус "только для чтения" в то время, как эти файлы копируются. Эти файлы копируются неизмененными.

*.MYD

Данные о таблице MyISAM.

База данных помещается в статус "только для чтения" в то время, как эти файлы копируются. Эти файлы копируются неизмененными.

*.MYI

Данные об индексе MyISAM.

База данных помещается в статус "только для чтения" в то время, как эти файлы копируются. Эти файлы копируются неизмененными.

*.CSM

Метаданные для таблиц CSV.

Эти файлы копируются неизмененными. Таблицы backup_history и backup_progress, составленные mysqlbackup, используют формат CSV, таким образом, резервная копия всегда включает некоторые файлы с этим расширением.

*.CSV

Данные для таблиц CSV.

Эти файлы копируются неизмененными. Таблицы backup_history и backup_progress, составленные mysqlbackup, используют формат CSV, таким образом, резервная копия всегда включает некоторые файлы с этим расширением.

*.MRG

Ссылки механизма хранения MERGE на другие таблицы.

База данных помещается в статус "только для чтения" в то время, как эти файлы копируются. Эти файлы копируются неизмененными.

*.ARM

Метаданные таблицы механизма хранения ARCHIVE.

База данных помещается в статус "только для чтения" в то время, как эти файлы копируются. Эти файлы копируются неизмененными.

*.ARZ

Данные о таблице механизма хранения ARCHIVE.

База данных помещается в статус "только для чтения" в то время, как эти файлы копируются. Эти файлы копируются неизмененными.

backup-my.cnf

Делает запись параметров конфигурации, которые определяют расположение файлов данных MySQL.

Используемый в восстановлении, чтобы воспроизвести то же самое расположение как тогда, когда резервная копия была сделана.

ibbackup_ibd_files

Названия файлов .ibd files и их ID во время инкрементного резервного копирования.

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

ibbackup_logfile

Сжатая версия файлов ib_logfile* из каталога данных MySQL.

Файлы журнала InnoDB (файлы ib_logfile*) это файлы фиксированного размера, которые непрерывно обновляются во время действия базы данных. В целях резервирования необходимы только изменения, которые передаются в то время, как резервная копия происходит. Эти изменения зарегистрированы в ibbackup_logfile и используются, чтобы воссоздать файлы ib_logfile* во время фазы apply-log.

ibbackup_redo_log_only

Создан вместо ibbackup_logfile для возрастающих резервных копий, сделанных с опцией --incremental-with-redo-log-only.

ib_logfile*

Создан в резервном каталоге mysqlbackup во время шага apply-log после первоначальной резервной копии.

Эти файлы не копируются из оригинального каталога данных, а скорее воссоздаются в резервном каталоге во время шага apply-log после первоначальной резервной копии, используя изменения, зарегистрированные в файле ibbackup_logfile.

Каталог метки времени, например, 2011-05-26_13-42-02

Создан опцией --with-timestamp. Все резервные файлы входят в этот подкаталог.

Используя опцию --with-timestamp, легко держать больше, чем один набор данных резервного копирования в соответствии с тем же самым главным резервным каталогом.

Каталог datadir

Подкаталог, который хранит файлы данных и подкаталоги базы данных от оригинального экземпляра MySQL.

Создан в соответствии с резервным каталогом mysqlbackup.

Двоичные файлы журнала

 Двоичные файлы журнала от сервера, которые включены в резервную копию по умолчанию (кроме тех случаев, когда резервная копия создается с опцией --use-tts). Они позволяют снимку сервера быть взятым, таким образом, сервер может быть клонирован к его точному состоянию. Используя полное резервное копирование как основание, двоичные файлы журнала, которые включены с инкрементным резервным копированием, могут использоваться для восстановления момента времени (PITR), которое вернуло базу данных к ее состоянию в определенный момент времени после последнего полного резервного копирования. Посмотрите раздел 5.3.

Сохранен под каталогом datadir в резервной копии. Копия индексного файла на сервере MySQL, который перечисляет все используемые двоичные файлы журнала с местоположениями двоичных файлов журнала, правильно обновленных, чтобы указать на местоположения файлов в резервной копии, также включена в резервную копию в каталоге datadir. Используйте опцию --skip-binlog, чтобы исключить двоичный журнал из резервной копии.

По умолчанию двоичные файлы журнала и индексный файл вернутся на то же самое место, где они были найдены на поддержанном сервере. Используйте опцию --log-bin, чтобы определить иное целевое местоположение. Используйте опцию --skip-binlog, чтобы пропустить восстановление двоичного журнала.

Файлы двоичного журнала сжаты и сохранены с расширением .bz, будучи включенными в сжатую резервную копию.

  • MySQL Enterprise Backup 8.0.18 и ранее: сли какие-либо двоичные файлы журнала отсутствуют на сервере, необходимо использовать --skip-binlog, чтобы mysqlbackup не выдавал ошибки для недостающих файлов.

  • Никакие двоичные файлы журнала не копируются в инкрементное резервное копирование, если использованы опции --use-tts или --start-lsn. Чтобы включать двоичные файлы журнала в течение периода, покрытого инкрементным резервным копированием, не используйте опцию --use-tts, а вместо --start-lsn примените --incremental-base, которая предоставляет необходимую информацию для mysqlbackup, чтобы гарантировать, что никакой промежуток не существует между данными двоичного журнала, включенными в предыдущую резервную копию и текущим инкрементным резервным копированием.

  • Никакие двоичные файлы журнала не восстановлены на сервере с частичным восстановлением.

Файлы журнала реле

 Файлы журнала реле от сервера точной копии, которые включены в резервную копию сервера точной копии по умолчанию (кроме тех случаев, когда резервная копия создается с опцией --use-tts). Их включение экономит время и ресурсы, требуемые для установки журнала реле из источника, когда точная копия восстанавливается.

Сохранен в каталоге datadir в соответствии с резервным каталогом. Копия индексного файла на сервере точной копии, который перечисляет все используемые файлы журнала реле с местоположениями файлов журнала реле, правильно обновленных, чтобы указать на местоположения файлов в резервном каталоге, также включена в резервную копию, в каталоге datadir. Примените опцию --skip-relaylog , чтобы исключить журнал реле из резервной копии.

По умолчанию файлы журнала реле и индексный файл вернутся на те же места, где они были найдены на поддержанном сервере. Используйте --relay-log, чтобы определить иное целевое местоположение для журнала реле. Используйте --skip-relaylog , чтобы пропустить восстановление журнала реле.

Никакие файлы журнала реле не восстановлены на сервере с частичным восстановлением.

Файлы журнала реле сжаты и сохранены с расширением .bz, будучи включенными в сжатую резервную копию.

*.bz

 Сжатая двоичная регистрация или файлы журнала реле.

Двоичная регистрация и файлы журнала реле сжаты и сохранены с расширением .bz, будучи включенными в сжатую резервную копию. Они развернуты во время восстановления.

Файлы журнала отмены

Файлы журнала отмены, см. Undo Tablespaces.

8.0.16 и раньше: активное и бездействующее табличные пространства включены в резервную копию. Кроме того, когда опция --incremental-with-redo-log-only используется для создания возрастающих резервных копий, mysqlbackup создает из журнала отката журнал отмены в течение периода, покрытого инкрементным резервным копированием, и включает его в резервную копию.

Сохранен по умолчанию в каталоге datadir в резервной копии. Используйте опцию --backup_innodb_undo_directory, чтобы определить другое местоположение для журнала отмены.

8.0.15 и раньше: табличные пространства отмены вернутся в то местоположение, на которое указывает опция --innodb_undo_directory.

8.0.16 и раньше: при восстановлении табличные пространства отмены по умолчанию, а также любые табличные пространства отмены не по умолчанию в каталоге данных поддержанного сервера вернутся к местоположению, на которое указывает опция --innodb_undo_directory. Внешние табличные пространства отмены вернутся к местоположениям, в которых они были найдены на поддержанном сервере, чтобы изменить это редактируйте файл tablespace_tracker.

Никакие файлы журнала отмены не восстановлены на сервере с частичным восстановлением.

*.uz

 Сжатые файлы журнала отмены.

Файлы журнала отмены сжаты и сохранены с расширением .uz, будучи включенными в сжатую резервную копию. Они развернуты во время восстановления.

Зашифрованный файл данных брелка

Для сервера, использующего плагин keyring_encrypted_file, файл, определенный опцией keyring_encrypted_file_data на сервере, копируется в резервную копию с его настоящим именем в каталог meta.

Для сервера, использующего плагин не keyring_encrypted_file, файл keyring_kef сохранен в каталоге meta.

 Зашифрованный файл, содержащий главный ключ для шифрования таблицы InnoDB. См. раздел 6.

Файлы журнала статуса точной копии

 Обычно называются master.info и relay-log.info, включены по умолчанию в резервной копии базы данных точной копии в установке репликации. Посмотрите Replication Metadata Repositories.

Сохранен в каталоге datadir в соответствии с резервным каталогом.

Копирование этих файлов пропускается во время резервной копии или восстановления, когда использована опция --skip-relay-log.

Файл образа резервной копии

Однофайловое резервное копирование, произведенное опцией backup-to-image с именем, определенным опцией --backup-image.

Можно переместить файл образа не повреждая его содержание, затем распаковать его с mysqlbackup командой extract и определением того же самого названия образа опцией --backup-image. Хотя некоторые дополнительные файлы, такие как backup-my.cnf и подкаталог meta присутствует в резервном каталоге, эти файлы также включены в файл образа и не должны быть перемещены с ним.

Любые другие файлы в подкаталогах каталога datadir (то есть backup-dir/datadir/subdir).

Скопированы с подкаталогов базы данных в соответствии с каталогом данных MySQL.

По умолчанию любые непризнанные файлы в подкаталогах в соответствии с каталогом данных MySQL копируются к резервной копии. Чтобы пропустить такие файлы, определите опцию --only-known-file-types.

Некоторые ограничения относятся к этому поведению. Посмотрите обсуждение здесь.

Каталог meta

Подкаталог, который хранит файлы с метаданными о резервной копии.

Создан в соответствии с резервным каталогом mysqlbackup. Все упомянутые ниже файлы входят в подкаталог meta.

backup_variables.txt

Содержит важную информацию о резервной копии. Для использования mysqlbackup.

mysqlbackup консультируется и возможно обновляет этот файл во время операций после первоначальной резервной копии, таких как фаза apply-log или восстановления.

image_files.xml

Содержит список всех файлов (кроме себя), которые присутствуют в однофайловом резервном копировании, произведенном опциями backup-to-image или backup-dir-to-image. Для получения дополнительной информации об этом файле посмотрите раздел 17.4.

Этот файл не изменяется ни на какой стадии.

backup_create.xml

Перечисляет параметры командной строки и окружающую среду, в которой была создана резервная копия. Для получения дополнительной информации об этом файле посмотрите раздел 17.4.

Этот файл не изменяется, как только он создается. Можно препятствовать тому, чтобы этот файл был произведен, определив опцию the --disable-manifest.

backup_content.xml

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

Этот файл не изменяется. Можно препятствовать тому, чтобы этот файл был произведен, определив опцию --disable-manifest.

comments.txt

Произведен опцией --comments или --comments-file.

Комментарии определяются вами, чтобы зарегистрировать цель или специальные замечания для этого задания резервного копирования.

backup_gtid_executed.sql

Показывает, что резервная копия прибыла из сервера с позволенным GTID.

GTID это функция репликации в MySQL 5.6 и выше. Посмотрите Replication with Global Transaction Identifiers. Когда вы резервируете сервер с GTID, используя mysqlbackup, файл backup_gtid_executed.sql создается в каталоге meta в соответствии с резервным каталогом. Отредактируйте и выполните этот файл после восстановления данных резервного копирования на сервере точной копии, посмотрите раздел 8.1.

Для резервных копий TTS для серверов точной копии используйте опцию --slave-info для генерации backup_gtid_executed.sql.

server-my.cnf

Содержит значения глобальных переменных поддержанного сервера, которые установлены в значения не по умолчанию. Используйте этот файл или server-all.cnf, чтобы запустить целевой сервер для восстановления.

При выполнении copy-back или copy-back-and-apply-log значения server repository options (например, --datadir , --innodb_data_home_dir и т.д.) в файле изменяются, если команда вносит изменения в них через варианты команды. Однако, во время apply-incremental-backup значения, уже сохраненные в файле, имеют приоритет и не изменяются значениями опций, поставляемыми через команду.

Используя файл, чтобы перезапустить целевой сервер, измените такие параметры как --tmpdir, --general-log и любые глобальные переменные, которые используют абсолютный путь к файлу, чтобы избежать случайного использования неправильного расположения файлов целевым сервером.

server-all.cnf

Содержит значения всех глобальных переменных поддержанного сервера. Используйте этот файл или server-my.cnf, чтобы запустить целевой сервер для восстановления.

При выполнении copy-back или copy-back-and-apply-log значения server repository options (например, --datadir , --innodb_data_home_dir и т.д.) в файле изменяются, если команда вносит изменения в них через варианты команды. Однако, во время apply-incremental-backup значения, уже записанные в файле, имеет приоритет и не изменяются опциями.

Используя файл, чтобы перезапустить целевой сервер, измените такие параметры, как --tmpdir, --general-log и любые глобальные переменные, которые используют абсолютный путь к файлу, чтобы избежать случайного использования неправильного расположения файлов целевым сервером.

backup-auto.cnf

Копия файла auto.cnf от поддержанного сервера.

Файл восстановлен в каталог данных восстановленного сервера. Чтобы использовать UUID, сохраненный внутри для вашего восстановленного сервера, переименуйте файл назад к auto.cnf прежде, чем вы запустите сервер.

backup-mysqld-auto.cnf

Копия файла mysqld-.cnf от поддержанного сервера.

Файл восстановлен в каталог данных восстановленного сервера. Чтобы использовать сохраненные системные переменные, сохраненные внутри для вашего восстановленного сервера, переименуйте файл назад к mysqld-auto.cnf прежде, чем вы запустите сервер.

ib_buffer_pool

Файл произведен на сервере, когда включена innodb_buffer_pool_dump_at_shutdown (включена по умолчанию для MySQL 5.7.7 и позже) или innodb_buffer_pool_dump_now. Это хранит список ID табличных пространств и страниц пула буферов сервера.

Фактическое имя файла могло бы отличаться, поскольку оно может формироваться системной переменной сервера innodb_buffer_pool_filename.

С настройкой по умолчанию на сервере MySQL 5.7.7 и выше (innodb_buffer_pool_load_at_startup=ON), целевой сервер во время запуска собирается восстановить состояние пула буферов поддержанного сервера, используя этот файл. Посмотрите Saving and Restoring the Buffer Pool State.

tablespace_tracker

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

Если какое-либо внешнее табличное пространство существует на поддержанном сервере, файл трекера будет найден в каталоге datadir в резервной копии. Измените server_file_path в файле для любого табличного пространства, если вы хотите изменить восстановить местоположение для того табличного пространства (должен использоваться абсолютный путь). Чтобы получить доступ к файлу в однофайловом резервном копировании, используйте команду extract.

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

  • 8.0.16 и позже: Вы не можете изменить местоположение для восстановления табличного пространства отмены по умолчанию базы данных, редактируя запись server_file_path. Это местоположение восстановления управляется опцией --innodb_undo_directory.

После того, как восстановление закончено, если восстановленный сервер содержит какое-либо внешнее табличное пространство, файл трекера будет найден в каталоге данных восстановленного сервера.

1.3.2. Файлы, поддержанные для данных InnoDB

InnoDB-связанные файлы данных, которые поддерживаются, включают файлы ibdata* (которые представляют системное табличное пространство и возможно данные для некоторых пользовательских таблиц), любые файлы .ibd (которые содержат данные из пользовательских таблиц, составленных с опцией file-per-table) и данные из файлов ib_logfile* (изменения данных журналов отката, которые происходят в то время, как резервная копия работает), которые сохранены в новом резервном файле ibbackup_logfile.

При использовании функции сжатого резервного копирования, файлы .ibd переименованы в их сжатой форме к файлам .ibz.

Поддержанные файлы, поскольку они первоначально копируются, формируют сырую резервную копию, которая требует последующей обработки. Шаг apply (как часть команд copy-back-and-apply-log или backup-and-apply-log или же как отдельное действие apply-log) обновляет поддержанные файлы на основе изменений, зарегистрированных в файле ibbackup_logfile. В этом пункте данные соответствуют единственному моменту времени.

Чтобы избежать параллелизма во время изготовления резервных копий занятых баз данных, можно использовать опцию --only-innodb, чтобы поддержать только таблицы InnoDB и связанные данные.

1.3.3. Файлы, поддержанные для данных, хранимых MyISAM и другими механизмами хранения

mysqlbackup также поддерживает файлы .MYD, .MYI и .sdi, связанные с таблицами MyISAM. Файлы с другими расширениями, которые поддерживаются, показывают в таблице 1.1.

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

Таблицы MyISAM и другие типы файлов не могут быть поддержаны без блокировки, как таблицы InnoDB. Они могут быть поддержаны, используя теплую резервную копию, изменения этих таблиц предотвращены в то время, как они поддерживаются, возможно делая базу данных неактивной какое-то время, но никакое закрытие не требуется во время резервной копии.

1.3.4. Файлы, произведенные mysqlbackup

В файле образа резервного копирования, созданном командой backup-to-image есть некоторые новые файлы, которые производятся во время процесса резервного копирования. Эти файлы используются, чтобы управлять более поздними задачами, такими как подтверждение и восстановление данных резервного копирования. Файлы, произведенные во время процесса резервного копирования, включают:

  • meta/backup_create.xml: Перечисляет параметры командной строки и окружающую среду, в которой была создана резервная копия.

  • meta/backup_content.xml: Существенные метаданные для файлов и определений базы данных данных резервного копирования.

  • backup-my.cnf: Делает запись решающих параметров конфигурации, которые относятся к резервной копии. Эти параметры конфигурации прочитаны mysqlbackup во время операций вроде apply-log, чтобы определить, как данные резервного копирования структурированы. Эти параметры также проверяются во время восстановления операции на их совместимость с конфигурацией вашего целевого сервера.

  • server-my.cnf: Содержит значения глобальных переменных поддержанного сервера, которые установлены в значения не по умолчанию.

  • server-all.cnf: Содержит значения всех глобальных переменных поддержанного сервера.

  • *.bkt: Файл передачи создается для зашифрованной таблицы InnoDB во время резервной копии. Это содержит повторно зашифрованный ключ табличного пространства и другую информацию, связанную с шифрованием. См. раздел 6.

Для деталей о прочих файлах, содержащихся в резервной копии, см. таблицу 1.1.

1.4. Процесс резервного копирования

Следующее это очень краткая схема шагов, выполненных mysqlbackup, когда это создает резервную копию. Это не включает каждый шаг mysqlbackup и представляет только очень общий случай, процесс может выглядеть очень отличающимся, в зависимости от резервных вариантов, которые вы используете (особенно с некоторыми вариантами, описанными в разделах 20.10 и 20.16). Это описание относится только к MySQL Enterprise Backup 8.0.16 и позже.

В целом это описывает то, что происходит, когда вы управляете операцией резервного копирования с mysqlbackup:

  1. Файлы данных InnoDB, журнал отката, двоичный журнал и файлы журнала реле (за исключением использующихся в настоящее время файлов журнала) копируются в резервную копию в то время, как сервер базы данных работает, как обычно.

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

  2. Резервная блокировка применяется на сервере. Это блокирует операции DDL (за исключением тех, которые выполняются на созданных пользователями временных таблицах), но не операции DML (за исключением не захваченных двоичной регистрацией, как административные изменения базы данных) на таблицах InnoDB. Большинство чтений и записей все еще позволены. С этой блокировкой mysqlbackup просматривает таблицы InnoDB, которые были изменены операциями DDL, начиная с шага 1, и вносит изменения в резервную копию соответственно.

  3. Выполняется команда A FLUSH TABLES tbl_name [, tbl_name] ... WITH READ LOCK на всех не-InnoDB таблицах (для 8.0.18 и позже, только на не-InnoDB таблицах, которые должны быть включены в резервную копию), после чего копируются любые не-InnoDB таблицы, относящиеся к резервной копии.

    Этот шаг пропускается, если созданные пользователями не-InnoDB таблицы не существуют в базе данных.

  4. Краткое блокирование регистрации по серверу применяется для того, чтобы mysqlbackup мог собрать связанную с регистрацией информацию, такую как текущий InnoDB LSN, положение двоичной регистрации, GTID, источник репликации или статус точной копии и так далее.

  5. Блокировки чтения таблиц не-InnoDB снимаются.

  6. Используя информацию от шага 4 выше, копируется соответствующая часть двоичного журнала или использующегося в настоящее время файла журнала реле. Это гарантирует, что все недавние изменения таблиц InnoDB, начиная с шага 1, захватываются в резервной копии, таким образом, они могут быть применены позже к сырым данным резервного копирования, чтобы привести восстановленный сервер в последовательное состояние.

  7. Резервная блокировка сервера выпущена. База данных теперь возвращается к ее нормальному функционированию.

  8. Файлы журнала отката, еще не скопированные прежде, а также все файлы метаданных для резервной копии, копируются или создаются.

  9. Операция резервного копирования закончена.

Поиск

  

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

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