16.2.3.2 Monitoring Replication Applier Worker Threads — MySQL 5.7

16.2.3.2 Мониторинг потоков обработки репликации

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

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

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