19.5.1.35 Replication and Transaction Inconsistencies — MySQL 9.2

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

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

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

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

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

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

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

В некоторых особых ситуациях, как указано в описании 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, где есть разрывы.