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

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

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

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

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

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

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

Содержит метаданные обо всех таблицах MySQL.

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

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

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

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

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

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

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

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

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

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

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

Параметры триггеров.

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

Информация о пространстве имён триггеров.

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

Информация о конфигурации базы данных.

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

Определения для разнесённых таблиц.

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

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

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

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

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

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

Файл создаётся во время резервного копирования и содержит важные параметры, описывающие данные, которые были заархивированы, такие как , , , и так далее. Он также может содержать другие параметры InnoDB, такие как и , если во время резервного копирования использовались некоторые параметры репозитория резервной копии. mysqlbackup использует параметры, хранящиеся в этом файле, для понимания структуры резервной копии и выполнения различных операций. Возможно, вам потребуется предоставить некоторые из этих параметров mysqlbackup во время восстановления и mysqld при запуске целевого сервера, если целевой сервер и резервная копия настроены по-разному. Подробности см. в разделе 4.2.4, «Восстановление базы данных».

Записывает имена файлов .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.

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

Файл .isl создаётся, когда вы указываете расположение таблицы InnoDB, используя синтаксис CREATE TABLE ... DATA DIRECTORY = ... (см. для получения подробностей) или когда таблица переведена в (только для MySQL 5.7 и более поздних версий; см. для получения подробностей). Файл .isl действует как символическая ссылка, указывающая на файл пространства таблиц. Файлы .bl могут или не могут быть преобразованы обратно в файлы .isl во время операции copy-back или copy-back-and-apply-log. Если указанный каталог не существует на сервере, на котором восстанавливается резервная копия, mysqlbackup пытается создать его. Если каталог создать не удаётся, операция восстановления завершается неудачно. Таким образом, если вы хотите использовать предложение DATA DIRECTORY для размещения таблиц в разных местах или для восстановления на сервере с другой структурой файлов, где соответствующие каталоги создать невозможно, отредактируйте файлы .bl перед восстановлением, чтобы указать на каталоги, которые существуют на целевом сервере.

При восстановлении резервной копии, созданной с , если каталог на целевом сервере, на который указывает файл .bl, уже содержит файлы .ibd, необходима опция --force при восстановлении резервной копии.

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

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

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

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

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

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

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

Для релизов 4.1.1 и более ранних версий: Файлы журнала бинарных логов и файл индекса восстанавливаются в каталоге данных восстановленного сервера. Используйте опцию --skip-binlog, чтобы пропустить восстановление журнала бинарных логов.

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

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

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

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

Для релизов 4.1.1 и более ранних версий: Файлы журнала ретрансляции и файл индекса восстанавливаются в каталоге данных восстановленного сервера. Используйте опцию --skip-relaylog, чтобы пропустить восстановление журнала ретрансляции.

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

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

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

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

Сохраняются в каталоге datadir в каталоге резервной копии. Для автономной резервной копии используйте опции --master-info-file и --relaylog-info-file, чтобы указать абсолютные пути к файлам информации, если они отличаются от значений по умолчанию опций, чтобы mysqlbackup мог найти эти файлы и включить их в резервные копии.

Копирование этих файлов пропускается во время резервного копирования или восстановления, когда используется опция --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. Подробности об этом файле см. в Разделе 13.4, «Использование манифеста MySQL Enterprise Backup».

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

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

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

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

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

Создаётся с помощью опции --comments или --comments-file.

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

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

GTID — это функция репликации в MySQL 5.6 и выше. Подробности см. Когда вы создаёте резервную копию сервера с включёнными GTID с помощью mysqlbackup, файл с именем backup_gtid_executed.sql создаётся в папке meta в каталоге резервной копии. Отредактируйте и выполните этот файл после восстановления данных резервной копии на сервере-реплике; см. Раздел 7.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 значения, уже сохранённые в файле, имеют приоритет, и они не изменяются значениями опций, переданными через команду.

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

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

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