第274回　Group Replicationの状態をPerformance Schemaから確認しよう

これまで連載では、Group Replicationの基本的な仕組みや構築方法、Single-PrimaryとMulti-Primaryの違いや、Flow Controlなどを紹介してきました。Group Replicationを動かしたあとに気になるのが、クラスタが正常に動いているかをどこで確認すればよいのかです。Group Replicationでは複数のPerformance Schemaテーブルに状態が分かれて表示されます。

そこで本記事では Group Replication関連のテーブルの見方について解説します。

Group Replication 用のテーブル

Group Replicationをインストールした環境では、Performance Schemaにreplication_groupから始まるテーブルが作成されます。今回はDockerで3台構成のGroup Replicationクラスタを作って確認しています。

SHOW TABLESで見てみると、実際にテーブルが5つ追加されていることがわかります。

SHOW TABLES FROM performance_schema LIKE 'replication_group%';
+---------------------------------------------------+
| Tables_in_performance_schema (replication_group%) |
+---------------------------------------------------+
| replication_group_communication_information       |
| replication_group_configuration_version           |
| replication_group_member_actions                  |
| replication_group_member_stats                    |
| replication_group_members                         |
+---------------------------------------------------+

それぞれのテーブルの役割は以下の通りです。

テーブル	役割
`replication_group_members`	クラスタの構成
`replication_group_member_stats`	トランザクションの滞留
`replication_group_communication_information`	クラスタの通信状態
`replication_group_configuration_version`	メンバーアクション設定のバージョン
`replication_group_member_actions`	イベントに対して実行されるアクション

また、Group Replication固有ではないですが、以下のテーブルではGroup Replicationが内部で作成するApplier、Recoveryチャネルの状態を確認できます。

replication_connection_status
replication_applier_status
replication_applier_status_by_worker

メンバーの状態を確認する

最初に確認したいのがreplication_group_membersです。現在グループに参加しているメンバーとその状態が表示されます。今回の3台構成では次のように表示されました。

SELECT MEMBER_ID, MEMBER_HOST, MEMBER_PORT, MEMBER_STATE, MEMBER_ROLE, MEMBER_VERSION, MEMBER_COMMUNICATION_STACK
FROM performance_schema.replication_group_members;
+--------------------------------------+-------------+-------------+--------------+-------------+----------------+----------------------------+
| MEMBER_ID                            | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION | MEMBER_COMMUNICATION_STACK |
+--------------------------------------+-------------+-------------+--------------+-------------+----------------+----------------------------+
| 1e574920-7245-11f1-b914-1a7835472dc4 | gr1         |        3306 | ONLINE       | PRIMARY     | 9.7.1          | XCom                       |
| 63c4ed82-7245-11f1-bcc2-be4d6715b6cb | gr2         |        3306 | ONLINE       | SECONDARY   | 9.7.1          | XCom                       |
| d6516cea-7245-11f1-bf5e-c2c93b02c858 | gr3         |        3306 | ONLINE       | SECONDARY   | 9.7.1          | XCom                       |
+--------------------------------------+-------------+-------------+--------------+-------------+----------------+----------------------------+

通常時は想定した台数のメンバーが表示され、すべてONLINEになっていることが確認できます。MEMBER_STATEの値には以下の種類があります。

ONLINE：正常にグループへ参加している
RECOVERING：不足しているデータを取得している
OFFLINE：メンバーがGroup Replicationのグループに参加していない
ERROR：エラーにより正常にグループへ参加できていない
UNREACHABLE：他のメンバーから到達できないと疑われている

もしこの値が長時間RECOVERINGから変わらない場合やERRORになっている場合は、Recoveryチャネルやエラーログを確認する必要があるでしょう。また、MEMBER_ROLEにはPRIMARYまたはSECONDARYが表示されます。Single-Primaryでは書き込み先の確認に使えますし、Multi-PrimaryではすべてのメンバーがPRIMARYと表示されます。

適用遅延や競合を確認する

メンバー一覧だけでは、各ノードがトランザクションを処理できているかまではわかりません。そこで利用するのがreplication_group_member_statsです。

MEMBER_IDはUUIDなので、メンバー一覧と結合して表示すると分かりやすくなります。起動直後でトランザクションの滞留がない状態では、次のように各カウンタが0になっていることがわかります。

SELECT
  m.MEMBER_HOST, m.MEMBER_STATE, s.COUNT_TRANSACTIONS_IN_QUEUE,
  s.COUNT_TRANSACTIONS_REMOTE_IN_APPLIER_QUEUE, s.COUNT_CONFLICTS_DETECTED, s.COUNT_TRANSACTIONS_LOCAL_ROLLBACK
FROM performance_schema.replication_group_members AS m
JOIN performance_schema.replication_group_member_stats AS s
  ON m.MEMBER_ID = s.MEMBER_ID;
+-------------+--------------+-----------------------------+--------------------------------------------+--------------------------+-----------------------------------+
| MEMBER_HOST | MEMBER_STATE | COUNT_TRANSACTIONS_IN_QUEUE | COUNT_TRANSACTIONS_REMOTE_IN_APPLIER_QUEUE | COUNT_CONFLICTS_DETECTED | COUNT_TRANSACTIONS_LOCAL_ROLLBACK |
+-------------+--------------+-----------------------------+--------------------------------------------+--------------------------+-----------------------------------+
| gr1         | ONLINE       |                           0 |                                          0 |                        0 |                                 0 |
| gr2         | ONLINE       |                           0 |                                          0 |                        0 |                                 0 |
| gr3         | ONLINE       |                           0 |                                          0 |                        0 |                                 0 |
+-------------+--------------+-----------------------------+--------------------------------------------+--------------------------+-----------------------------------+

COUNT_TRANSACTIONS_IN_QUEUEは、このメンバーで競合検出待ちになっているトランザクション数です。これに対し、COUNT_TRANSACTIONS_REMOTE_IN_APPLIER_QUEUEは、競合検出を通過したリモートトランザクションが、そのメンバーでの適用を待っている件数です。もしこの値が増え続けている場合、そのメンバーのApplierがグループから届く更新へ追いつけていない可能性があります。Flow Controlが発生したときにも確認したい値です。

COUNT_CONFLICTS_DETECTEDは、競合検出に失敗したトランザクション数です。Multi-Primaryで複数ノードから同じ行を更新した場合などに増える可能性があります。

COUNT_TRANSACTIONS_LOCAL_ROLLBACKは、そのメンバーで実行したもののグループによってロールバックされたトランザクション数です。

通信状態を確認する

ネットワーク関連の情報はreplication_group_communication_informationで確認できます。

SELECT
  PROTOCOL_VERSION,
  WRITE_CONCURRENCY,
  MEMBER_FAILURE_SUSPICIONS_COUNT
FROM performance_schema.replication_group_communication_information;
+------------------+-------------------+------------------------------------------------------------------------------------------------------------------------------+
| PROTOCOL_VERSION | WRITE_CONCURRENCY | MEMBER_FAILURE_SUSPICIONS_COUNT                                                                                              |
+------------------+-------------------+------------------------------------------------------------------------------------------------------------------------------+
| 8.0.27           |                10 | {"344d7c91-7198-11f1-9be5-920289a93e0f":0,"98cc3afa-7197-11f1-be79-be91f778567d":0,"d65476be-7197-11f1-acd3-52b8d112f39a":0} |
+------------------+-------------------+------------------------------------------------------------------------------------------------------------------------------+

MEMBER_FAILURE_SUSPICIONS_COUNTには、このノードから見て各メンバーを通信不能と疑った回数がJSON形式で表示されます。現在は全メンバーがONLINEでも、過去に一時的な通信断が疑われていなかったかを確認する手がかりになります。

WRITE_CONCURRENCYは、グループが合意形成を並列に実行できる最大数を表します。通常の状態確認では出番が少ないものの、通信や合意形成まで調べる場合に利用できます。

RecoveryやApplierを詳しく確認する

Group Replicationでは、主に次の2つのレプリケーションチャネルが作成されます。

group_replication_applier：グループから受信したトランザクションを適用する
group_replication_recovery：グループ参加時のRecoveryで利用する

たとえば、Group Replication関連チャネルの状態と直近エラーの概要は次のように確認できます。今回のPrimaryで確認すると、ApplierはON、Recoveryは参加完了後なのでOFFになっていました。

SELECT
  CHANNEL_NAME,
  SERVICE_STATE,
  LAST_ERROR_NUMBER,
  LAST_ERROR_MESSAGE
FROM performance_schema.replication_connection_status
WHERE CHANNEL_NAME IN ('group_replication_applier', 'group_replication_recovery')
ORDER BY CHANNEL_NAME;
+----------------------------+---------------+-------------------+--------------------+
| CHANNEL_NAME               | SERVICE_STATE | LAST_ERROR_NUMBER | LAST_ERROR_MESSAGE |
+----------------------------+---------------+-------------------+--------------------+
| group_replication_applier  | ON            |                 0 |                    |
| group_replication_recovery | OFF           |                 0 |                    |
+----------------------------+---------------+-------------------+--------------------+

Applier Workerごとのエラーは次のテーブルから確認できます。

SELECT
  CHANNEL_NAME,
  WORKER_ID,
  SERVICE_STATE,
  APPLYING_TRANSACTION,
  LAST_ERROR_NUMBER,
  LAST_ERROR_MESSAGE
FROM performance_schema.replication_applier_status_by_worker
WHERE CHANNEL_NAME = 'group_replication_applier';
+---------------------------+-----------+---------------+----------------------+-------------------+--------------------+
| CHANNEL_NAME              | WORKER_ID | SERVICE_STATE | APPLYING_TRANSACTION | LAST_ERROR_NUMBER | LAST_ERROR_MESSAGE |
+---------------------------+-----------+---------------+----------------------+-------------------+--------------------+
| group_replication_applier |         1 | ON            |                      |                 0 |                    |
| group_replication_applier |         2 | ON            |                      |                 0 |                    |
| group_replication_applier |         3 | ON            |                      |                 0 |                    |
| group_replication_applier |         4 | ON            |                      |                 0 |                    |
+---------------------------+-----------+---------------+----------------------+-------------------+--------------------+

LAST_ERROR_NUMBERが0以外の場合や、SERVICE_STATEがOFFになっているWorkerがある場合は、エラーログと合わせて原因を確認します。

まとめ

このようにPerformance SchemaではGroup Replicationの状態を色々と見ることができます。Performance Schemaは現在の状態を見るのに向いています。一方、メンバーの参加・離脱、Primaryの選出、UNREACHABLEからの復帰、Distributed Recoveryの開始などはエラーログへ記録されます。そのため、まずはPerformance Schemaで状態を確認し、必要に応じてエラーログなどを確認するのが良いでしょう。