19.2.4.2 Репозитории метаданных репликации
Сервер реплики создает два репозитория метаданных репликации: репозиторий метаданных подключения и репозиторий метаданных применяющего процесса. Репозитории метаданных репликации сохраняются после завершения работы сервера реплики. Если используется репликация на основе позиции файла бинарного лога, при перезапуске реплики она считывает два репозитория, чтобы определить, до какой точки она ранее прочитала бинарный лог источника и обработала свой релейный лог. Если используется репликация на основе GTID, реплика не использует репозитории метаданных репликации для этой цели, но нуждается в них для других хранящихся в них метаданных.
Репозиторий метаданных подключения реплики содержит информацию, необходимую потоку ввода-вывода репликации (приемнику), чтобы подключиться к серверу источника репликации и извлечь транзакции из бинарного лога источника. Метаданные в этом репозитории включают конфигурацию подключения, данные учетной записи пользователя репликации, настройки SSL для подключения и имя файла и позицию, с которой поток приемника репликации в настоящее время читает бинарный лог источника.
Репозиторий метаданных применяющего процесса реплики содержит информацию, необходимую потоку SQL репликации (применяющему процессу), чтобы прочитать и применить транзакции из релейного лога реплики. Метаданные в этом репозитории включают имя файла и позицию, до которой поток применяющего процесса репликации выполнил транзакции в релейном логе, и эквивалентную позицию в бинарном логе источника. Он также содержит метаданные для процесса применения транзакций, такие как количество потоков-рабочих и
PRIVILEGE_CHECKS_USERучетную запись канала.
Репозиторий метаданных подключения записывается в таблицу slave_master_info в схеме системы mysql, а репозиторий метаданных применяющего процесса записывается в таблицу slave_relay_log_info в схеме системы mysql. Если mysqld не может инициализировать таблицы для репозиториев метаданных репликации, выводится сообщение об ошибке, но реплика разрешается продолжить запуск. Такая ситуация наиболее вероятна при обновлении с версии MySQL, не поддерживающей использование таблиц для репозиториев, на версию, где это поддерживается.
Не пытайтесь вручную обновлять или вставлять строки в таблицы
mysql.slave_master_infoилиmysql.slave_relay_log_info. Это может привести к неопределенному поведению и не поддерживается. Выполнение любого оператора, требующего блокировки записи на одной или обеих таблицахslave_master_infoиslave_relay_log_info, запрещено во время работы репликации (хотя операторы, выполняющие только чтение, разрешены в любое время).Права доступа к таблице репозитория метаданных подключения
mysql.slave_master_infoдолжны быть ограничены администратором базы данных, так как она содержит имя и пароль учетной записи пользователя репликации для подключения к источнику. Используйте режим ограниченного доступа для защиты резервных копий базы данных, включающих эту таблицу. Вы можете очистить учетные данные пользователя репликации из репозитория метаданных подключения и вместо этого всегда предоставлять их с помощью оператораSTART REPLICAдля запуска канала репликации. Такой подход означает, что для перезапуска канала репликации всегда требуется вмешательство оператора, но имя и пароль учетной записи не записываются в репозитории метаданных репликации.
RESET REPLICA очищает данные в репозиториях метаданных репликации, за исключением параметров подключения репликации (в зависимости от версии MySQL Server). Подробности см. в описании оператора RESET REPLICA.
Вы можете установить опцию GTID_ONLY оператора CHANGE REPLICATION SOURCE TO, чтобы предотвратить сохранение имен файлов и позиций в репозиториях метаданных репликации. Это предотвращает записи и чтения в таблицы в ситуациях, когда репликация на основе GTID на самом деле их не требует. С настройкой GTID_ONLY репозитории метаданных подключения и применяющего процесса не обновляются при очередении и применении событий репликой в транзакции или при остановке и запуске потоков репликации. Позиции файлов отслеживаются в памяти и могут быть просмотрены с помощью SHOW REPLICA
STATUS, если они нужны. Репозитории метаданных репликации синхронизируются только в следующих случаях:
При выполнении оператора
CHANGE REPLICATION SOURCE TO.При выполнении оператора
RESET REPLICA.RESET REPLICA ALLудаляет, а не обновляет репозитории, поэтому они синхронизируются неявно.При инициализации канала репликации.
Если репозитории метаданных репликации перемещены из файлов в таблицы.
Создание репозиториев метаданных репликации в виде таблиц является стандартным, использование файлов устарело.
Таблицы 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. Для внешнего использования информация о состоянии потоков-рабочих представлена в таблице схемы производительности replication_applier_status_by_worker.
Репозитории метаданных репликации изначально содержали информацию, аналогичную той, которая отображается в выводе оператора SHOW REPLICA STATUS, о котором рассказывается в Разделе 15.4.2, «Операторы SQL для управления серверами реплики». Впоследствии в репозитории метаданных репликации добавлена дополнительная информация, не отображаемая оператором SHOW REPLICA STATUS.
Для репозитория метаданных подключения следующая таблица показывает соответствие между столбцами в таблице mysql.slave_master_info, столбцами, отображаемыми оператором SHOW REPLICA STATUS, и строками в устаревшем файле master.info.
slave_master_info Столбец таблицы |
SHOW REPLICA STATUS Столбец |
master.info Строка файла | Описание |
|---|---|---|---|
Number_of_lines | [None] | 1 | Количество столбцов в таблице (или строк в файле) |
Master_log_name | Source_Log_File | 2 | Имя двоичного журнала, который в данный момент считывается со источника |
Master_log_pos | Read_Source_Log_Pos | 3 | Текущая позиция в двоичном журнале, прочитанном со источника |
Host | Source_Host | 4 | Имя хоста сервера репликации-источника |
User_name | Source_User | 5 | Имя учетной записи пользователя репликации, используемой для подключения к источнику |
User_password | Пароль (не отображается в SHOW REPLICA
STATUS) | 6 | Пароль учетной записи пользователя репликации, используемой для подключения к источнику |
Port | Source_Port | 7 | Сеть порт, используемый для подключения к серверу репликации-источнику |
Connect_retry | Connect_Retry | 8 | Период (в секундах), который реплика ожидает перед попыткой повторного подключения к источнику |
Enabled_ssl | Source_SSL_Allowed | 9 | Поддерживает ли реплика подключения SSL |
Ssl_ca | Source_SSL_CA_File | 10 | Файл, используемый для сертификата Центра сертификации (CA) |
Ssl_capath | Source_SSL_CA_Path | 11 | Путь к файлу сертификата Центра сертификации (CA) |
Ssl_cert | Source_SSL_Cert | 12 | Имя файла SSL-сертификата |
Ssl_cipher | Source_SSL_Cipher | 13 | Список возможных шифров, используемых в рукопожатии для SSL-соединения |
Ssl_key | Source_SSL_Key | 14 | Имя файла SSL-ключа |
Ssl_verify_server_cert | Source_SSL_Verify_Server_Cert | 15 | Требовать проверку серверного сертификата |
Heartbeat | [None] | 16 | Интервал между сердцебиениями репликации в секундах |
Bind | Source_Bind | 17 | Какой из сетевых интерфейсов реплики должен использоваться для подключения к источнику |
Ignored_server_ids | Replicate_Ignore_Server_Ids | 18 | Список идентификаторов серверов, которые следует игнорировать. Обратите внимание, что для Ignored_server_ids список идентификаторов серверов предваряется общим количеством идентификаторов серверов для игнорирования. |
Uuid | Source_UUID | 19 | Уникальный идентификатор источника |
Retry_count | Source_Retry_Count | 20 | Максимальное количество разрешенных попыток повторного подключения |
Ssl_crl | [None] | 21 | Путь к файлу списка отзыва SSL-сертификатов |
Ssl_crlpath | [None] | 22 | Путь к каталогу, содержащему файлы списка отзыва SSL-сертификатов |
Enabled_auto_position | Auto_position | 23 | Используется ли автоматическое позиционирование GTID |
Channel_name | Channel_name | 24 | Имя канала репликации |
Tls_version | Source_TLS_Version | 25 | Версия TLS на источнике |
Public_key_path | Source_public_key_path | 26 | Имя файла открытого ключа RSA |
Get_public_key | Get_source_public_key | 27 | Запрашивать ли открытый ключ RSA у источника |
Network_namespace | Network_namespace | 28 | Сетевое пространство имен |
Master_compression_algorithm | [None] | 29 | Разрешенные алгоритмы сжатия для подключения к источнику |
Master_zstd_compression_level | [None] | 30 |
zstd уровень сжатия |
Tls_ciphersuites | [None] | 31 | Разрешенные наборы шифров для TLSv1.3 |
Source_connection_auto_failover | [None] | 32 | Активирован ли механизм аварийного переключения асинхронного соединения |
Gtid_only | [None] | 33 | Использует ли канал только GTID и не сохраняет позиции |
Для хранилища метаданных приложения следующая таблица показывает соответствие столбцов в таблице mysql.slave_relay_log_info, столбцов, отображаемых SHOW REPLICA STATUS, и строк устаревшего файла relay-log.info.
slave_relay_log_info Столбец таблицы |
SHOW REPLICA STATUS Столбец | Строка в файле relay-log.info | Описание |
|---|---|---|---|
Number_of_lines | [None] | 1 | Количество столбцов в таблице или строк в файле |
Relay_log_name | Relay_Log_File | 2 | Имя текущего файла журнала ретрансляции |
Relay_log_pos | Relay_Log_Pos | 3 | Текущая позиция в файле журнала ретрансляции; события до этой позиции были выполнены в базе данных реплики |
Master_log_name | Relay_Source_Log_File | 4 | Имя файла двоичного журнала источника, из которого были прочитаны события в файле журнала ретрансляции |
Master_log_pos | Exec_Source_Log_Pos | 5 | Эквивалентная позиция в файле двоичного журнала источника событий, которые были выполнены в реплике |
Sql_delay | SQL_Delay | 6 | Количество секунд, на которое реплика должна отставать от источника |
Number_of_workers | [None] | 7 | Количество потоков обработчиков для одновременного применения транзакций репликации |
Id | [None] | 8 | Идентификатор, используемый для внутренних целей; в настоящее время он всегда равен 1 |
Channel_name | Channel_name | 9 | Имя канала репликации |
Privilege_checks_username | [None] | 10 | Имя пользователя для учетной записи PRIVILEGE_CHECKS_USER для канала |
Privilege_checks_hostname | [None] | 11 | Имя хоста для учетной записи PRIVILEGE_CHECKS_USER для канала |
Require_row_format | [None] | 12 | Принимает ли канал только события на основе строк |
Require_table_primary_key_check | [None] | 13 | Политика канала относительно необходимости наличия первичных ключей у таблиц для операций CREATE TABLE и ALTER
TABLE |
Assign_gtids_to_anonymous_transactions_type | [None] | 14 | Если канал присваивает GTID реплицированным транзакциям, которые его еще не имеют, используя локальный UUID реплики, это значение является LOCAL; если канал делает это, используя вместо этого UUID, который был задан вручную, значение является UUID. Если канал не присваивает GTID в таких случаях, значение является OFF. |
Assign_gtids_to_anonymous_transactions_value | [None] | 15 | UUID, используемый в GTID, присвоенных анонимным транзакциям |
© 2025 Oracle
Licensed under the GPLv2 License.
