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

Репозиторий метаданных соединения записывается в таблицу slave_master_info в схеме системы mysql, а репозиторий метаданных приложения записывается в таблицу slave_relay_log_info в схеме системы mysql. Выводится сообщение об ошибке, если mysqld не может инициализировать таблицы для репозиториев метаданных репликации, но реплика разрешает продолжить запуск. Такая ситуация чаще всего возникает при обновлении с версии MySQL, не поддерживающей использование таблиц для репозиториев, на версию, которая их поддерживает.

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

Вы можете установить параметр GTID_ONLY оператора CHANGE REPLICATION SOURCE TO, чтобы канал репликации прекратил сохранение имен файлов и позиций файлов в репозиториях метаданных репликации. Это предотвращает запись и чтение в таблицы в ситуациях, когда репликация на основе GTID фактически не требует их. С настройкой GTID_ONLY репозитории метаданных соединения и приложения не обновляются при очереди и применении репликой событий в транзакции или при остановке и запуске потоков репликации. Позиции файлов отслеживаются в памяти и могут быть просмотрены с помощью SHOW REPLICA STATUS, если они необходимы. Репозитории метаданных репликации синхронизируются только в следующих ситуациях:

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

Таблицы mysql.slave_master_info и mysql.slave_relay_log_info создаются с помощью транзакционного хранилища данных InnoDB. Обновления таблицы репозитория метаданных приложения выполняются вместе с транзакциями, что означает, что информация о прогрессе реплики, записанная в этом репозитории, всегда согласована с тем, что было применено к базе данных, даже в случае неожиданной остановки сервера. Сведения о комбинации настроек реплики, обеспечивающей наибольшую устойчивость к неожиданным остановкам, см. в Разделе 19.4.2, «Обработка неожиданной остановки реплики».

При создании резервной копии данных реплики или передаче снимка данных для создания новой реплики убедитесь, что вы включаете таблицы mysql.slave_master_info и mysql.slave_relay_log_info, содержащие репозитории метаданных репликации. Для операций клонирования обратите внимание, что при создании репозиториев метаданных репликации как таблиц они копируются к получателю во время операции клонирования, а при создании их как файлов — нет. При использовании репликации на основе позиции файла бинарного лога репозитории метаданных репликации необходимы для возобновления репликации после перезапуска восстановленной, скопированной или клонированной реплики. Если у вас нет файлов релейного лога, но есть репозиторий метаданных приложения, вы можете проверить его, чтобы определить, насколько далеко поток SQL репликации выполнил операции в бинарном логе источника. Затем вы можете использовать оператор CHANGE REPLICATION SOURCE TO с параметрами SOURCE_LOG_FILE и SOURCE_LOG_POS, чтобы указать реплике повторно прочитать бинарные логи источника с этой точки (при условии, что требуемые бинарные логи все еще существуют на источнике).

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

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

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

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