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

По умолчанию репозитории метаданных репликации создаются как файлы в каталоге данных, имеющие имена master.info и relay-log.info, или с альтернативными именами и расположениями, указанными параметром --master-info-file и системной переменной relay_log_info_file. Для создания репозиториев метаданных репликации в виде таблиц укажите master_info_repository=TABLE и relay_log_info_repository=TABLE при запуске сервера. В этом случае репозиторий метаданных подключения реплики записывается в таблицу slave_master_info в системной схеме mysql, а репозиторий метаданных аппликатоpa реплики записывается в таблицу slave_relay_log_info в системной схеме mysql. Если mysqld не может инициализировать таблицы для репозиториев метаданных репликации, выводится сообщение об ошибке, но запуск реплики разрешается продолжить. Такая ситуация наиболее вероятна при обновлении с версии MySQL, не поддерживающей использование таблиц для репозиториев, на версию, в которой они поддерживаются.

RESET SLAVE очищает данные в репозиториях метаданных репликации, за исключением параметров подключения к репликации (в зависимости от выпуска MySQL Server и типа репозитория). Подробности см. в описании для RESET SLAVE.

Если вы установите master_info_repository и relay_log_info_repository в значение TABLE, таблицы mysql.slave_master_info и mysql.slave_relay_log_info создаются с использованием транзакционного хранилища данных InnoDB. Обновления в таблице репозитория метаданных аппликатоpa реплики выполняются вместе с транзакциями, что означает, что информация о прогрессе реплики, записанная в этом репозитории, всегда согласована с тем, что было применено к базе данных, даже в случае непредвиденной остановки сервера. Необходимо включить параметр --relay-log-recovery на реплике для обеспечения устойчивости. Более подробную информацию см. в разделе 16.3.2 «Обработка непредвиденной остановки реплики».

При резервном копировании данных реплики или переносе моментального снимка данных для создания новой реплики убедитесь, что вы включаете таблицы mysql.slave_master_info и mysql.slave_relay_log_info, содержащие репозитории метаданных репликации, или эквивалентные файлы (master.info и relay-log.info в каталоге данных, если вы не указали альтернативные имена и расположения). Если используется репликация на основе позиции файла бинарного журнала, репозитории метаданных репликации необходимы для возобновления репликации после перезапуска восстановленной или скопированной реплики. Если у вас нет файлов журнала реле, но у вас есть репозиторий метаданных аппликатоpa реплики, вы можете проверить его, чтобы определить, насколько далеко поток SQL репликации выполнил транзакции в бинарном журнале источника. Затем вы можете использовать оператор CHANGE MASTER TO с параметрами MASTER_LOG_FILE и MASTER_LOG_POS, чтобы указать реплике повторно прочитать бинарные журналы из источника с этой точки (при условии, что необходимые бинарные журналы все еще существуют на источнике).

Дополнительный репозиторий, репозиторий метаданных потоков-обработчиков аппликатоpa, создается в основном для внутреннего использования и содержит информацию о состоянии потоков-обработчиков на реплике с несколькими потоками. Репозиторий метаданных потоков-обработчиков аппликатоpa включает имена и позиции файла журнала реле и файла бинарного журнала источника для каждого потока-обработчика. Если репозиторий метаданных аппликатоpa реплики создается как таблица, что является по умолчанию, репозиторий метаданных потоков-обработчиков аппликатоpa записывается в таблицу mysql.slave_worker_info. Если репозиторий метаданных аппликатоpa записывается в файл, репозиторий метаданных потоков-обработчиков аппликатоpa записывается в файл worker-relay-log.info. Для внешнего использования информация о состоянии потоков-обработчиков представлена в таблице Performance Schema replication_applier_status_by_worker.

Репозитории метаданных репликации первоначально содержали информацию, аналогичную той, что отображается в выводе оператора SHOW SLAVE STATUS, которая обсуждается в разделе 13.4.2 «SQL-операторы для управления серверами репликации». В дальнейшем в репозитории метаданных репликации были добавлены дополнительные данные, не отображаемые оператором SHOW SLAVE STATUS.

Для репозитория метаданных подключения следующая таблица показывает соответствие между столбцами таблицы mysql.slave_master_info, столбцами, отображаемыми оператором SHOW SLAVE STATUS, и строками в файле master.info.

Для хранилища метаданных применяющего приложения следующая таблица показывает соответствие столбцов таблицы mysql.slave_relay_log_info, столбцов, отображаемых командой SHOW SLAVE STATUS и строк в файле relay-log.info.

В версиях MySQL до MySQL 5.6 файл relay-log.info не содержит количество строк или значение задержки (и таблица slave_relay_log_info недоступна).

Содержимое файла relay-log.info и состояния, отображаемые командой SHOW SLAVE STATUS, могут не совпадать, если файл relay-log.info не был записан на диск. В идеале вы должны просматривать relay-log.info только на реплике, которая находится в автономном режиме (то есть, mysqld не работает). Для работающей системы вы можете использовать SHOW SLAVE STATUS, или запросить таблицы mysql.slave_master_info и mysql.slave_relay_log_info, если вы записываете хранилища метаданных репликации в таблицы.