20.4 Мониторинг групповой репликации
Для мониторинга групповой репликации можно использовать MySQL Performance Schema. Эти таблицы Performance Schema отображают информацию, специфичную для групповой репликации:
Эти таблицы репликации Performance Schema также отображают информацию, относящуюся к групповой репликации:
replication_connection_statusотображает информацию о групповой репликации, такую как транзакции, полученные от группы и очереди в очереди приложения (журнал переадресации).replication_applier_statusотображает состояния каналов и потоков, относящихся к групповой репликации. Их также можно использовать для мониторинга того, чем занимаются отдельные потоки рабочих процессов.
Каналы репликации, созданные плагином групповой репликации, перечислены здесь:
group_replication_recovery: Используется для репликации изменений, связанных с распределенным восстановлением.group_replication_applier: Используется для входящих изменений из группы для применения транзакций, поступающих непосредственно из группы.
Сведения о системных переменных, влияющих на групповую репликацию, см. в разделе 20.9.1, «Системные переменные групповой репликации». См. раздел 20.9.2, «Переменные состояния групповой репликации» для переменных состояния, предоставляющих информацию о групповой репликации.
Сообщения, относящиеся к жизненному циклу групповой репликации, отличные от ошибок, классифицируются как системные сообщения; они всегда записываются в журнал ошибок члена группы репликации. Вы можете использовать эту информацию для проверки истории членства данного сервера в группе репликации.
Некоторые события жизненного цикла, затрагивающие всю группу, регистрируются на каждом члене группы, например, вступление нового члена в состояние ONLINE в группе или выборы первичного узла. Другие события регистрируются только на том члене, где они происходят, например, включение или отключение супер-только-для-чтения режима на члене или выход члена из группы. Ряд событий жизненного цикла, которые могут указывать на проблему при частой их повторяемости, регистрируются как предупреждения, в том числе член становится недоступным, а затем снова доступным, и член начинает распределенное восстановление путем передачи состояния из двоичного журнала или с помощью удалённой операции клонирования.
Если вы отслеживаете один или несколько вторичных экземпляров с помощью mysqladmin, вам следует знать, что оператор FLUSH STATUS, выполненный этой утилитой, создает событие GTID на локальном экземпляре, что может повлиять на будущие операции группы.
© 2025 Oracle
Licensed under the GPLv2 License.