「パフォーマンススキーマ」が有効になっている場合は、「パフォーマンススキーマ」テーブルを使用してグループレプリケーションを監視します。 グループレプリケーションにより、次のテーブルが追加されます:
performance_schema.replication_group_member_statsperformance_schema.replication_group_members
これらのパフォーマンススキーマレプリケーションテーブルには、グループレプリケーションに関する情報も表示されます:
performance_schema.replication_connection_statusには、グループから受信してアプライヤキュー (リレーログ) にキューに入れられたトランザクションなど、グループレプリケーションに関する情報が表示されます。performance_schema.replication_applier_statusには、Group Replication 関連のチャネルおよびスレッドの状態が表示されます。トランザクションを適用するワーカースレッドが多数ある場合は、ワーカーテーブルを使用して、各ワーカースレッドの実行内容を監視することもできます。
Group Replication プラグインによって作成されるレプリケーションチャネルの名前は次のとおりです:
group_replication_recovery- このチャネルは、分散リカバリフェーズに関連するレプリケーション変更に使用されます。group_replication_applier- このチャネルは、グループからの着信変更に使用されます。 これは、グループから直接取得したトランザクションを適用するために使用されるチャネルです。
MySQL 8.0.21 からは、エラー以外の状況のグループレプリケーションライフサイクルイベントはシステムメッセージとして分類され、レプリケーショングループメンバーのサーバーエラーログに常に記録されます。 この情報を使用して、レプリケーショングループ内のサーバーメンバーシップの履歴を確認できます。 以前のリリースでは、エラー以外の状況のグループレプリケーションライフサイクルイベントは情報メッセージとして分類され、サーバーに log_error_verbosity レベル 3 を指定することでエラーログに追加できました。
グループ全体に影響するライフサイクルイベントの中には、グループで ONLINE ステータスになった新しいメンバーやプライマリ選択など、すべてのグループメンバーに記録されるものがあります。 他のイベントは、メンバーで有効化または無効化されているスーパー読取り専用モードやグループを離れたメンバーなど、発生したメンバーにのみ記録されます。 頻繁に発生した場合に問題を示すことができる多数のライフサイクルイベントは、メンバーが到達不能になり再度到達可能になるなどの警告メッセージとしてログに記録され、メンバーはバイナリログまたはリモートクローニング操作からの状態転送によって分散リカバリを開始します。
次の各セクションでは、グループレプリケーションで使用可能な監視情報を解釈する方法について説明します。