19.5.1.34 Replication and Transaction Inconsistencies — MySQL 8.4

19.5.1.34 Несоответствия в репликации и транзакциях

Несоответствия в последовательности транзакций, выполненных из журнала репликации, могут возникать в зависимости от вашей конфигурации репликации. Этот раздел объясняет, как избежать несоответствий и решить любые проблемы, которые они вызывают.

Могут существовать следующие типы несоответствий:

Неполностью применённые транзакции. Транзакция, обновляющая нетранзакционные таблицы, применила некоторые, но не все свои изменения.
Пропуски. Пропуск в наборе внешних транзакций появляется, когда, при заданной упорядоченной последовательности транзакций, транзакция, которая расположена позже в последовательности, применяется до какой-либо другой транзакции, которая расположена ранее в последовательности. Пропуски могут появляться только при использовании многопотоковой реплики.

Чтобы избежать пропусков на многопотоковой реплике, установите replica_preserve_commit_order=ON. Это значение по умолчанию, поскольку все реплики по умолчанию многопотоковые.

Для установки replica_preserve_commit_order=ON не требуется ведение журнала двоичных логов и журнала обновлений реплики на реплике, и эти журналы могут быть отключены, если это необходимо.

Установка replica_preserve_commit_order=ON требует, чтобы replica_parallel_type было установлено в LOGICAL_CLOCK. В MySQL 8.4 это значение по умолчанию.

В некоторых особых ситуациях, как указано в описании для replica_preserve_commit_order, установка replica_preserve_commit_order=ON не может сохранить порядок фиксации на реплике, поэтому в этих случаях пропуски могут всё ещё появляться в последовательности транзакций, которые были выполнены из журнала репликации реплики.

Установка replica_preserve_commit_order=ON не предотвращает отставание позиции двоичного лога источника.
Отставание позиции двоичного лога источника. Даже в отсутствие пропусков, возможно, что транзакции после Exec_master_log_pos были применены. То есть, все транзакции до точки N были применены, и никакие транзакции после N не были применены, но Exec_master_log_pos имеет значение, меньшее чем N. В этой ситуации Exec_master_log_pos является “нижней границей” применённых транзакций и отстаёт от позиции последней применённой транзакции. Это может произойти только на многопотоковых репликах. Включение replica_preserve_commit_order не предотвращает отставание позиции двоичного лога источника.

Следующие сценарии актуальны для существования неполностью применённых транзакций, пропусков и отставания позиции двоичного лога источника:

Во время работы потоков репликации могут возникать пропуски и неполностью применённые транзакции.
mysqld завершает работу. Как чистое, так и нечистое завершение работы прерывают текущие транзакции и могут привести к пропусков и неполностью применённых транзакций.
KILL потоков репликации (потока SQL при использовании однопотоковой реплики, координационного потока при использовании многопотоковой реплики). Это прерывает текущие транзакции и может привести к пропусков и неполностью применённых транзакций.
Ошибка в потоках-применителях. Это может привести к пропусков. Если ошибка произошла в смешанной транзакции, эта транзакция является неполностью применённой. При использовании многопотоковой реплики рабочие потоки, которые не получили ошибку, завершают свои очереди, поэтому может потребоваться время для остановки всех потоков.
STOP REPLICA при использовании многопотоковой реплики. После выдачи STOP REPLICA, реплика ждёт, пока любые пропуски не будут заполнены, а затем обновляет Exec_master_log_pos. Это гарантирует, что она никогда не оставит пропусков или отставания позиции двоичного лога источника, если не происходит ни один из вышеперечисленных случаев, то есть до того, как STOP REPLICA завершится, происходит ошибка, другой поток выдаёт KILL или сервер перезапускается. В этих случаях STOP REPLICA возвращает успешное значение.
Если последняя транзакция в журнале репликации получена только наполовину, а координационный поток многопотоковой реплики начал планировать транзакцию для рабочего потока, то STOP REPLICA ждёт до 60 секунд для получения транзакции. После этого таймаута координатор отказывается и прерывает транзакцию. Если транзакция смешанная, она может быть завершена наполовину.
STOP REPLICA, когда текущая транзакция обновляет только транзакционные таблицы, в этом случае она откатывается, и STOP REPLICA останавливается немедленно. Если текущая транзакция смешанная, STOP REPLICA ждёт до 60 секунд для завершения транзакции. После этого таймаута она прерывает транзакцию, поэтому она может быть завершена наполовину.

Глобальное значение системной переменной rpl_stop_replica_timeout не имеет отношения к процессу остановки потоков репликации. Она только заставляет клиента, который выдаёт STOP REPLICA, вернуть ответ клиенту, но потоки репликации продолжают пытаться остановиться.

Если в канале репликации есть пропуски, это имеет следующие последствия:

База данных реплики находится в состоянии, которое могло никогда не существовать на источнике.
Поле Exec_master_log_pos в SHOW REPLICA STATUS является только “нижней границей”. Другими словами, транзакции, появляющиеся до указанной позиции, гарантированно завершены, но транзакции после этой позиции могут быть завершены или нет.
CHANGE REPLICATION SOURCE TO для этого канала завершаются с ошибкой, если только потоки-применители работают, и оператор лишь задаёт параметры приёмника.
Если mysqld запускается с --relay-log-recovery, восстановление не выполняется для этого канала, и выводится предупреждение.
Если mysqldump используется с --dump-replica, он не записывает существование пропусков; поэтому он печатает CHANGE REPLICATION SOURCE TO с RELAY_LOG_POS, установленным в позицию “нижней границы” в Exec_master_log_pos.

После применения дампа на другом сервере и запуска потоков репликации транзакции, появляющиеся после указанной позиции, будут снова реплицироваться. Обратите внимание, что это безвредно, если включены GTID (однако в этом случае не рекомендуется использовать --dump-replica).

Если в канале репликации есть отставание позиции двоичного лога источника, но нет пропусков, пункты 2—5 выше применимы, но пункт 1 не применим.

Информация о позиции двоичного лога источника сохраняется в двоичном формате во внутренней таблице mysql.slave_worker_info. START REPLICA [SQL_THREAD] всегда использует эту информацию, чтобы применять только правильные транзакции. Это остается верным даже если replica_parallel_workers было изменено на 0 до START REPLICA, и даже если START REPLICA используется с UNTIL. START REPLICA UNTIL SQL_AFTER_MTS_GAPS применяет только необходимое количество транзакций для заполнения пропусков. Если START REPLICA используется с UNTIL, которые сообщают ей остановиться до того, как она потребляет все пропуски, тогда она оставляет оставшиеся пропуски.

Предупреждение

RESET REPLICA удаляет журналы репликации и сбрасывает позицию репликации. Таким образом, выдача RESET REPLICA на многопотоковой реплике с пропусками означает, что реплика теряет любую информацию о пропусках, без исправления пропусков. В этой ситуации, если используется репликация на основе позиции двоичного лога, процесс восстановления завершается неудачно.

При использовании репликации на основе GTID (GTID_MODE=ON) и SOURCE_AUTO_POSITION задано для канала репликации с помощью инструкции CHANGE REPLICATION SOURCE TO, старые журналы релеев не требуются для процесса восстановления. Вместо этого реплика может использовать автоматическое позиционирование GTID для расчёта пропущенных транзакций по сравнению с источником. Процесс, используемый для репликации на основе позиции двоичного лога для устранения разрывов на многопотоковой реплике, полностью пропущен при использовании репликации на основе GTID. Когда этот процесс пропущен, инструкция START REPLICA UNTIL SQL_AFTER_MTS_GAPS ведет себя иначе и не пытается проверить разрывы в последовательности транзакций. Вы также можете использовать инструкции CHANGE REPLICATION SOURCE TO, которые запрещены для реплики, не использующей GTID, где есть разрывы.