19.4.11 Delayed Replication — MySQL 9.2

19.4.11 Задержка репликации

MySQL поддерживает задержку репликации, при которой сервер-реплика намеренно выполняет транзакции позже, чем источник, по крайней мере, на заданный интервал времени. В этом разделе описывается, как настроить задержку репликации на реплике и как отслеживать задержку репликации.

В MySQL 9.2 метод задержки репликации зависит от двух временных меток, immediate_commit_timestamp и original_commit_timestamp (см. Временные метки задержки репликации); задержка репликации измеряется с использованием этих временных меток. Если непосредственный источник или реплика не используют эти временные метки, используется реализация задержки репликации из MySQL 5.7 (см. ). В этом разделе описывается задержка репликации между серверами, все из которых используют эти временные метки.

По умолчанию задержка репликации составляет 0 секунд. Используйте оператор CHANGE REPLICATION SOURCE TO SOURCE_DELAY=N, чтобы установить задержку на N секунд. Транзакция, полученная от источника, не выполняется до тех пор, пока не пройдет по крайней мере N секунд после её подтверждения в непосредственном источнике. Задержка применяется к каждой транзакции (а не к событию, как в предыдущих версиях MySQL), и фактическая задержка накладывается только на gtid_log_event или anonymous_gtid_log_event. Другие события в транзакции всегда следуют за этими событиями без наложения времени ожидания.

Примечание

START REPLICA и STOP REPLICA вступают в силу немедленно и игнорируют любую задержку. RESET REPLICA сбрасывает задержку до 0.

Таблица Performance Schema replication_applier_configuration содержит столбец DESIRED_DELAY, который показывает настроенную задержку с использованием опции SOURCE_DELAY. Таблица Performance Schema replication_applier_status содержит столбец REMAINING_DELAY, который показывает количество оставшихся секунд задержки.

Задержка репликации может использоваться для различных целей:

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

Временные метки задержки репликации

MySQL 9.2 предоставляет новый метод измерения задержки (также известной как отставание репликации) в топологиях репликации, который зависит от следующих временных меток, связанных с GTID каждой транзакции (вместо каждого события), записанных в бинарный журнал.

original_commit_timestamp: количество микросекунд с эпохи, когда транзакция была записана (подтверждена) в бинарный журнал исходного источника.
immediate_commit_timestamp: количество микросекунд с эпохи, когда транзакция была записана (подтверждена) в бинарный журнал непосредственного источника.

Вывод команды mysqlbinlog отображает эти временные метки в двух форматах: микросекунды с эпохи и также TIMESTAMP формате, основанном на пользовательской временной зоне для лучшей читабельности. Например:

#170404 10:48:05 server id 1  end_log_pos 233 CRC32 0x016ce647     GTID    last_committed=0
\ sequence_number=1    original_committed_timestamp=1491299285661130    immediate_commit_timestamp=1491299285843771
# original_commit_timestamp=1491299285661130 (2017-04-04 10:48:05.661130 WEST)
# immediate_commit_timestamp=1491299285843771 (2017-04-04 10:48:05.843771 WEST)
 /*!80001 SET @@SESSION.original_commit_timestamp=1491299285661130*//*!*/;
   SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1'/*!*/;
# at 233

Как правило, original_commit_timestamp одинакова на всех репликах, где применяется транзакция. В репликации источник-реплика, original_commit_timestamp транзакции в бинарном журнале (исходного) источника всегда совпадает с её immediate_commit_timestamp. В журнале репликации реплики, original_commit_timestamp и immediate_commit_timestamp транзакции совпадают с таковыми в бинарном журнале источника; в то время как в её собственном бинарном журнале, immediate_commit_timestamp транзакции соответствует момент, когда реплика подтвердила транзакцию.

В конфигурации Group Replication, когда исходный источник является членом группы, original_commit_timestamp генерируется, когда транзакция готова к подтверждению. Другими словами, когда она завершила выполнение на исходном источнике и её набор записей готов к отправке всем членам группы для сертификации. Когда исходный источник является сервером вне группы, original_commit_timestamp сохраняется. Та же самая original_commit_timestamp для конкретной транзакции реплицируется на все серверы в группе и на любые реплики за пределами группы, которые выполняют репликацию с члена. Каждый получатель транзакции также хранит локальное время подтверждения в своём бинарном журнале с использованием immediate_commit_timestamp.

События изменения отображения, которые являются уникальными для Group Replication, представляют собой особый случай. Транзакции, содержащие эти события, генерируются каждым членом группы, но разделяют один и тот же GTID (так что они не выполняются сначала в источнике, а затем реплицируются в группу, а все члены группы выполняют и применяют одну и ту же транзакцию). Члены группы устанавливают локальные значения временных меток для транзакций, связанных с событиями изменения отображения.

Отслеживание задержки репликации

Одним из наиболее распространённых способов отслеживания задержки репликации (отставания) в предыдущих версиях MySQL было использование поля Seconds_Behind_Master в выводе команды SHOW REPLICA STATUS. Однако эта метрика не подходит при использовании топологий репликации, более сложных, чем традиционная конфигурация источник-реплика, например, Group Replication. Добавление immediate_commit_timestamp и original_commit_timestamp в MySQL 8 обеспечивает более подробную информацию о задержке репликации. Рекомендуемый метод отслеживания задержки репликации в топологии, поддерживающей эти временные метки, заключается в использовании следующих таблиц Performance Schema.

replication_connection_status: текущее состояние подключения к источнику, предоставляет информацию о последней и текущей транзакции, помещённой потоком подключения в журнал репликации.
replication_applier_status_by_coordinator: текущее состояние координирующего потока, который отображает информацию только при использовании многопоточной реплики, предоставляет информацию о последней транзакции, буферизованной координирующим потоком в очередь рабочей нити, а также о транзакции, которую он в настоящее время буферизует.
replication_applier_status_by_worker: текущее состояние потока(ов), применяющих транзакции, полученные от источника, предоставляет информацию о транзакциях, применяемых потоком SQL репликации или каждой рабочей нитью при использовании многопоточной реплики.

Используя эти таблицы, можно отслеживать информацию о последней транзакции, обработанной соответствующим потоком, и о транзакции, которую поток в настоящее время обрабатывает. Эта информация включает:

GTID транзакции
original_commit_timestamp и immediate_commit_timestamp транзакции, полученные из журнала репликации реплики
время начала обработки транзакции потоком
для последней обработанной транзакции время завершения обработки потоком

В дополнение к таблицам Performance Schema, вывод команды SHOW REPLICA STATUS содержит три поля, которые показывают:

SQL_Delay: Положительное целое число, указывающее настроенную задержку репликации с использованием CHANGE REPLICATION SOURCE TO SOURCE_DELAY=N, где N измеряется в секундах.
SQL_Remaining_Delay: Если Replica_SQL_Running_State равно Waiting until SOURCE_DELAY seconds after master executed event, в этом поле содержится целое число, указывающее оставшиеся секунды задержки. В других случаях это поле равно NULL.
Replica_SQL_Running_State: Строка, указывающая состояние потока SQL (аналогично Replica_IO_State). Значение идентично значению State потока SQL, как показано командой SHOW PROCESSLIST.

Когда поток SQL репликации ожидает истечения задержки перед выполнением события, команда SHOW PROCESSLIST отображает его значение State как Waiting until SOURCE_DELAY seconds after master executed event.