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

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

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

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

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

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

Файлы .ibz распаковываются во время этапа apply-log, copy-back или copy-back-and-apply-log.

Хранят метаданные для таблиц MyISAM.

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

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

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

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

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

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

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

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

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

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

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

Метаданные таблиц движка хранения ARCHIVE.

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

Данные таблиц движка хранения ARCHIVE.

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

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

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

Записывает имена файлов .ibd и их идентификаторы пространства во время инкрементной резервной копии.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

На сервер с частичным восстановлением (частичным восстановлением) файлы журнала репликации не восстанавливаются.

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

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

Файлы журнала отката с сервера. Подробнее см.

В резервную копию включаются как активные, так и неактивные табличные пространства отката. Также, когда используется параметр --incremental-with-redo-log-only для создания инкрементных резервных копий, mysqlbackup создаёт из журнала пересчёта журнал отката на период, охватываемый инкрементной резервной копией, и включает его в резервную копию.

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

При восстановлении, табличные пространства отката по умолчанию, а также любые табличные пространства отката, не являющиеся табличными пространствами отката по умолчанию, расположенные в каталоге данных резервируемого сервера, восстанавливаются в расположение, указанное параметром mysqlbackup --innodb_undo_directory. Табличные пространства отката, не являющиеся табличными пространствами отката по умолчанию и внешние, восстанавливаются в места, где они были найдены на резервируемом сервере; измените расположения восстановления, отредактировав файл tablespace_tracker.

Файлы журнала отката не восстанавливаются на сервере с частичным восстановлением.

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

Для сервера, использующего компонент ключа шифрования component_keyring_encrypted_file, файл данных ключа шифрования, указанный в файле component_keyring_encrypted_file.cnf на сервере, копируется в резервную копию в папку meta и называется keyring_kef.

Для сервера, использующего плагин или компонент ключа шифрования, отличный от component_keyring_encrypted_file, создаётся и сохраняется файл данных ключа шифрования в папке meta с именем keyring_kef.

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

Сохраняются в каталоге datadir в каталоге резервной копии.

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

Единая резервная копия, созданная параметром backup-to-image, с именем, указанным параметром --backup-image.

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

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

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

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

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

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

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

Содержит список всех файлов (кроме самого себя), которые присутствуют в резервной копии, созданной параметрами backup-to-image или backup-dir-to-image. Подробности об этом файле см. в Разделе 17.4, «Использование макета MySQL Enterprise Backup».

Этот файл не изменяется на любом этапе после создания.

Перечисляет аргументы командной строки и среду, в которой была создана резервная копия. Подробности об этом файле см. в Разделе 17.4, «Использование макета MySQL Enterprise Backup».

Этот файл не изменяется после создания. Вы можете предотвратить создание этого файла, указав параметр --disable-manifest.

Необходимые метаданные для файлов и определений баз данных данных резервной копии. Он также содержит сведения обо всех плагинах, определённых на резервируемом сервере, поэтому пользователи должны убедиться, что те же плагины определены аналогичным образом на целевом сервере для восстановления. Подробности об этом файле см. в Разделе 17.4, «Использование макета MySQL Enterprise Backup».

Этот файл не изменяется после создания. Вы можете предотвратить создание этого файла, указав параметр --disable-manifest.

Создаётся параметром --comments или --comments-file.

Комментарии задаются вами для документирования цели или особых соображений для этого задания резервного копирования.

Указывает, что резервная копия создана с сервером, у которого включены GTID.

GTID — это функция репликации в MySQL 5.6 и более поздних версиях. Подробности см. в . При создании резервной копии сервера с включенными GTID с помощью mysqlbackup в папке meta под каталогом резервной копии создается файл с именем backup_gtid_executed.sql. Этот файл необходимо отредактировать и выполнить после восстановления данных резервной копии на сервере-реплике; подробности см. в разделе 8.1, «Настройка новой реплики».

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

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

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

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

Копия файла auto.cnf с резервируемого сервера.

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

Копия файла mysqld-.cnf с резервируемого сервера.

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

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

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

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

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

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

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