19.2.3.2 Monitoring Replication Applier Worker Threads — MySQL 9.2

19.2.3.2 Мониторинг потоков обработки приложения репликации

В реплике с несколькими потоками таблицы Performance Schema replication_applier_status_by_coordinator и replication_applier_status_by_worker отображают информацию о состоянии координатора реплики и потоков обработки приложения репликации соответственно. Для реплики с несколькими каналами потоки для каждого канала идентифицируются.

Поток координатора реплики с несколькими потоками также регулярно выводит статистику в журнал ошибок реплики, если уровень подробности настроен на отображение информационных сообщений. Статистика выводится в зависимости от объёма событий, которые поток координатора назначил потокам обработки приложения, с максимальной частотой один раз в 120 секунд. Сообщение перечисляет следующую статистику для соответствующего канала репликации или по умолчанию (без названия):

Прошедшие секунды: Разница во времени в секундах между текущим временем и последним временем отображения этой информации в журнале ошибок.
Назначенные события: Общее количество событий, которые поток координатора поместил в очередь всех потоков обработки приложения с момента запуска потока координатора.
Очереди рабочих заполнены сверх уровня переполнения: Текущее количество событий, помещенных в очередь любого из потоков обработки приложения, сверх уровня переполнения, установленного на 90% от максимальной длины очереди в 16384 события. Если это значение равно нулю, ни один из потоков обработки приложения не работает на предельной производительности.
Ожидание из-за заполненной очереди рабочих: Количество раз, когда потоку координатора приходилось ждать планирования события, потому что очередь потока обработки приложения была заполнена. Если это значение равно нулю, ни один из потоков обработки приложения не исчерпал свою пропускную способность.
Ожидание из-за общего размера: Количество раз, когда потоку координатора приходилось ждать планирования события, потому что был достигнут предел replica_pending_jobs_size_max. Эта системная переменная устанавливает максимальный объём памяти (в байтах), доступный для очередей потоков обработки приложения, содержащих события, которые ещё не применены. Если необычно большое событие превышает этот размер, транзакция удерживается до тех пор, пока все потоки обработки приложения не освободят свои очереди, а затем обрабатывается. Все последующие транзакции удерживаются до завершения большой транзакции.
Ожидание из-за конфликтов с часами: Количество наносекунд, которые потоку координатора приходилось ждать планирования события, потому что транзакция, от которой зависело событие, ещё не была подтверждена. Если replica_parallel_type установлено в DATABASE (а не в LOGICAL_CLOCK), это значение всегда равно нулю.
Ожидание (количество) при занятости рабочих: Количество раз, когда поток координатора приостанавливался на короткий период времени, что может происходить в двух ситуациях. В первой ситуации, когда поток координатора назначает событие и обнаруживает, что очередь потока обработки приложения заполнена сверх уровня недозаполнения (10% от максимальной длины очереди), в этом случае он приостанавливается не более чем на 1 миллисекунду. Во второй ситуации, когда replica_parallel_type установлено в LOGICAL_CLOCK, и потоку координатора необходимо назначить первое событие транзакции в очередь потока обработки приложения, он делает это только для рабочего с пустой очередью, поэтому если очереди пусты, поток координатора приостанавливается до тех пор, пока одна не станет пустой.
Время ожидания при занятости рабочих: Количество наносекунд, которые поток координатора приостанавливался, ожидая пустой очереди потока обработки приложения (то есть во второй ситуации, описанной выше, где replica_parallel_type установлено в LOGICAL_CLOCK, и первое событие транзакции необходимо назначить).