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

Вывод 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.

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

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

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