今回は、InnoDB Cluster, Group Replication の監視方法に関して紹介していきます。
パフォーマンススキーマのグループレプリケーション関連テーブルを把握する
まず基本的な情報として、Group Replication では通常の MySQL の監視項目に追加して監視すべきパフォーマンススキーマのテーブルがあります。
公式リファレンスマニュアルでは以下の章に記載されています。
MySQL :: MySQL 8.0 リファレンスマニュアル :: 18.3 グループレプリケーションの監視
まずはマニュアルにある概要を引用しつつ、どのテーブルで何の情報が得られるのかを改めて押さえておきましょう。
なお、各テーブルのカラムのひとつひとつの説明については、マニュアルを確認いただくこととして本記事では割愛致します。(URLを併記しました)
performance_schema.replication_group_members
MySQL :: MySQL 8.0 リファレンスマニュアル :: 18.3.2 replication_group_members テーブル
MySQL :: MySQL 8.0 リファレンスマニュアル :: 27.12.11.10 replication_group_members テーブル
performance_schema.replication_group_members テーブルは、グループのメンバーである様々なサーバーインスタンスのステータスの監視に使用されます。 新しいメンバーが結合されたときにグループの構成が動的に変更された場合など、ビューが変更されるたびにテーブルの情報が更新されます。 その時点で、サーバーはメタデータの一部を交換して同期し、連携を続行します。 この情報は、レプリケーショングループのメンバーであるすべてのサーバーインスタンス間で共有されるため、すべてのグループメンバーに関する情報を任意のメンバーからクエリーすることができます。 このテーブルを使用して、レプリケーショングループの状態の高レベルビューを取得できます。
グループメンバーに関する基礎情報(ID,ホスト名,ステータス,クラスタロール,バージョン)が確認できます。
グループの全体状況を確認する際に参照することが多いと思います。
|
1 2 3 4 5 6 7 8 9 |
SELECT * FROM performance_schema.replication_group_members; +---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+----------------------------+ | CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION | MEMBER_COMMUNICATION_STACK | +---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+----------------------------+ | group_replication_applier | c0644108-07ec-11ed-8f49-02001702a4b7 | gr-mysql-e1 | 3306 | ONLINE | PRIMARY | 8.0.29 | XCom | | group_replication_applier | c0657793-07ec-11ed-aad6-02001702fdc8 | gr-mysql-e3 | 3306 | ONLINE | SECONDARY | 8.0.29 | XCom | | group_replication_applier | c0680dbe-07ec-11ed-9666-020017021baf | gr-mysql-e2 | 3306 | ONLINE | SECONDARY | 8.0.29 | XCom | +---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+----------------------------+ 3 rows in set (0.0002 sec) |
performance_schema.replication_group_member_stats
MySQL :: MySQL 8.0 リファレンスマニュアル :: 18.3.3 replication_group_member_stats テーブル
MySQL :: MySQL 8.0 リファレンスマニュアル :: 27.12.11.11 replication_group_member_stats テーブル
レプリケーショングループ内の各メンバーは、グループが受信したトランザクションを証明して適用します。 証明者および適用者プロシージャに関する統計は、適用者キューの増加状況、検出された競合の数、チェックされたトランザクションの数、すべての場所でコミットされたトランザクションなどを理解するために役立ちます。
performance_schema.replication_group_member_stats テーブルには、証明プロセスに関連するグループレベルの情報と、レプリケーショングループの個々のメンバーが受信および発生したトランザクションの統計が表示されます。 この情報は、レプリケーショングループのメンバーであるすべてのサーバーインスタンス間で共有されるため、すべてのグループメンバーに関する情報を任意のメンバーからクエリーすることができます。
これらのフィールドは、グループに接続されているメンバーのパフォーマンスを監視するために重要です。 たとえば、グループのいずれかのメンバーが、他のメンバーと比較して常にキュー内の多数のトランザクションをレポートするとします。 これは、メンバーが遅延し、グループの他のメンバーと最新の状態を維持できないことを意味します。 この情報に基づいて、キューに入れられたトランザクションの数を減らすために、グループからメンバーを削除するか、グループの他のメンバーでトランザクションの処理を遅延するかを決定できます。 この情報は、Group Replication プラグインのフロー制御の調整方法の決定にも役立ちます。
※実際はメンバー分の出力が表示されますが、同一項目なので割愛しています。
マニュアルの説明にもある通り、このテーブルで確認できるトランザクションキューイング数の情報は Group Replication のパフォーマンス、特にレプリケーションの遅延状況を把握するうえで重要です。
また、全てのメンバーにコミット済みである GTIDセット(TRANSACTIONS_COMMITTED_ALL_MEMBERS)が確認できます。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
SELECT * FROM performance_schema.replication_group_member_stats\G *************************** 1. row *************************** CHANNEL_NAME: group_replication_applier VIEW_ID: 16582950451657311:7 MEMBER_ID: c0644108-07ec-11ed-8f49-02001702a4b7 COUNT_TRANSACTIONS_IN_QUEUE: 0 COUNT_TRANSACTIONS_CHECKED: 1520 COUNT_CONFLICTS_DETECTED: 0 COUNT_TRANSACTIONS_ROWS_VALIDATING: 2 TRANSACTIONS_COMMITTED_ALL_MEMBERS: 1a6ca389-07ed-11ed-9526-02001702a4b7:1-1509, 1a6ca709-07ed-11ed-9526-02001702a4b7:1-5, c0644108-07ec-11ed-8f49-02001702a4b7:1 LAST_CONFLICT_FREE_TRANSACTION: 1a6ca389-07ed-11ed-9526-02001702a4b7:1520 COUNT_TRANSACTIONS_REMOTE_IN_APPLIER_QUEUE: 0 COUNT_TRANSACTIONS_REMOTE_APPLIED: 5 COUNT_TRANSACTIONS_LOCAL_PROPOSED: 1520 COUNT_TRANSACTIONS_LOCAL_ROLLBACK: 0 (...) |
確認クエリの例
以下は、各メンバーの適用トランザクションキューイング数を取得するクエリの例です。
replication_group_member_stats テーブルではメンバーを識別できるカラムが MEMBER_ID のみで分かり辛いため、replication_group_members と結合して表示しています。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
SELECT MEMBER_HOST , MEMBER_ROLE , COUNT_TRANSACTIONS_IN_QUEUE , COUNT_TRANSACTIONS_REMOTE_IN_APPLIER_QUEUE FROM performance_schema.replication_group_member_stats t1 JOIN performance_schema.replication_group_members t2 ON t2.MEMBER_ID = t1.MEMBER_ID ORDER BY MEMBER_HOST; +-------------+-------------+-----------------------------+--------------------------------------------+ | MEMBER_HOST | MEMBER_ROLE | COUNT_TRANSACTIONS_IN_QUEUE | COUNT_TRANSACTIONS_REMOTE_IN_APPLIER_QUEUE | +-------------+-------------+-----------------------------+--------------------------------------------+ | gr-mysql-e1 | PRIMARY | 0 | 0 | | gr-mysql-e2 | SECONDARY | 0 | 0 | | gr-mysql-e3 | SECONDARY | 0 | 0 | +-------------+-------------+-----------------------------+--------------------------------------------+ |
各キューイング数が以下の条件で閾値超過した場合 Group Replication のフローコントロールが発動しプライマリ(ライター)ノードで更新処理のスロットルが発生しますので、パフォーマンス観点での重要な監視項目と言えます。
COUNT_TRANSACTIONS_IN_QUEUEがgroup_replication_flow_control_certifier_thresholdパラメータ(デフォルト:25,000)よりも大きい場合COUNT_TRANSACTIONS_REMOTE_IN_APPLIER_QUEUEがgroup_replication_flow_control_applier_thresholdパラメータ(デフォルト:25,000)よりも大きい場合
※フローコントロールの概要については、リファレンスマニュアルの以下ページを参照してください。
MySQL :: MySQL 8.0 リファレンスマニュアル :: 18.6.2 フロー制御
performance_schema.replication_connection_status
パフォーマンススキーマのレプリケーション情報用のテーブルにもグループレプリケーションに関する情報が載ってきます。
MySQL :: MySQL 8.0 リファレンスマニュアル :: 27.12.11.2 replication_connection_status テーブル
performance_schema.replication_connection_status には、グループから受信してアプライヤキュー (リレーログ) にキューに入れられたトランザクションなど、グループレプリケーションに関する情報が表示されます。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 |
SELECT * FROM performance_schema.replication_connection_status\G *************************** 1. row *************************** CHANNEL_NAME: group_replication_applier GROUP_NAME: 1a6ca389-07ed-11ed-9526-02001702a4b7 SOURCE_UUID: 1a6ca389-07ed-11ed-9526-02001702a4b7 THREAD_ID: NULL SERVICE_STATE: ON COUNT_RECEIVED_HEARTBEATS: 0 LAST_HEARTBEAT_TIMESTAMP: 0000-00-00 00:00:00.000000 RECEIVED_TRANSACTION_SET: 1a6ca389-07ed-11ed-9526-02001702a4b7:1-1713, 1a6ca709-07ed-11ed-9526-02001702a4b7:1-5, c0644108-07ec-11ed-8f49-02001702a4b7:1 LAST_ERROR_NUMBER: 0 LAST_ERROR_MESSAGE: LAST_ERROR_TIMESTAMP: 0000-00-00 00:00:00.000000 LAST_QUEUED_TRANSACTION: 1a6ca709-07ed-11ed-9526-02001702a4b7:5 LAST_QUEUED_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP: 2022-07-20 14:31:58.497672 LAST_QUEUED_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP: 2022-07-20 14:31:58.497672 LAST_QUEUED_TRANSACTION_START_QUEUE_TIMESTAMP: 2022-07-20 14:31:58.497698 LAST_QUEUED_TRANSACTION_END_QUEUE_TIMESTAMP: 2022-07-20 14:31:58.497711 QUEUEING_TRANSACTION: QUEUEING_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP: 0000-00-00 00:00:00.000000 QUEUEING_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP: 0000-00-00 00:00:00.000000 QUEUEING_TRANSACTION_START_QUEUE_TIMESTAMP: 0000-00-00 00:00:00.000000 1 row in set (0.0003 sec) |
performance_schema.replication_applier_status
MySQL :: MySQL 8.0 リファレンスマニュアル :: 27.12.11.5 replication_applier_status テーブル
performance_schema.replication_applier_status には、Group Replication 関連のチャネルおよびスレッドの状態が表示されます。トランザクションを適用するワーカースレッドが多数ある場合は、ワーカーテーブルを使用して、各ワーカースレッドの実行内容を監視することもできます。
|
1 2 3 4 5 6 7 |
SELECT * FROM performance_schema.replication_applier_status\G *************************** 1. row *************************** CHANNEL_NAME: group_replication_applier SERVICE_STATE: ON REMAINING_DELAY: NULL COUNT_TRANSACTIONS_RETRIES: 0 1 row in set (0.0002 sec) |
performance_schema.replication_applier_status_by_worker
ワーカーテーブル というのは、具体的には performance_schema.replication_applier_status_by_worker テーブルになります。
MySQL :: MySQL 8.0 リファレンスマニュアル :: 17.2.3.2 レプリケーションアプライアンスワーカースレッドの監視
MySQL :: MySQL 8.0 リファレンスマニュアル :: 27.12.11.7 replication_applier_status_by_worker テーブル
replica_parallel_workers で指定したスレッド数分、情報が表示されます。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 |
SELECT * FROM performance_schema.replication_applier_status_by_worker\G *************************** 1. row *************************** CHANNEL_NAME: group_replication_applier WORKER_ID: 1 THREAD_ID: 559 SERVICE_STATE: ON LAST_ERROR_NUMBER: 0 LAST_ERROR_MESSAGE: LAST_ERROR_TIMESTAMP: 0000-00-00 00:00:00.000000 LAST_APPLIED_TRANSACTION: 1a6ca709-07ed-11ed-9526-02001702a4b7:5 LAST_APPLIED_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP: 2022-07-20 14:31:58.497672 LAST_APPLIED_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP: 2022-07-20 14:31:58.497672 LAST_APPLIED_TRANSACTION_START_APPLY_TIMESTAMP: 2022-07-20 14:31:58.497755 LAST_APPLIED_TRANSACTION_END_APPLY_TIMESTAMP: 2022-07-20 14:31:58.498891 APPLYING_TRANSACTION: APPLYING_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP: 0000-00-00 00:00:00.000000 APPLYING_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP: 0000-00-00 00:00:00.000000 APPLYING_TRANSACTION_START_APPLY_TIMESTAMP: 0000-00-00 00:00:00.000000 LAST_APPLIED_TRANSACTION_RETRIES_COUNT: 0 LAST_APPLIED_TRANSACTION_LAST_TRANSIENT_ERROR_NUMBER: 0 LAST_APPLIED_TRANSACTION_LAST_TRANSIENT_ERROR_MESSAGE: LAST_APPLIED_TRANSACTION_LAST_TRANSIENT_ERROR_TIMESTAMP: 0000-00-00 00:00:00.000000 APPLYING_TRANSACTION_RETRIES_COUNT: 0 APPLYING_TRANSACTION_LAST_TRANSIENT_ERROR_NUMBER: 0 APPLYING_TRANSACTION_LAST_TRANSIENT_ERROR_MESSAGE: APPLYING_TRANSACTION_LAST_TRANSIENT_ERROR_TIMESTAMP: 0000-00-00 00:00:00.000000 *************************** 2. row *************************** CHANNEL_NAME: group_replication_applier WORKER_ID: 2 THREAD_ID: 560 SERVICE_STATE: ON (...) |
performance_schema.replication_applier_status_by_coordinator
もう一つ、(前後しますが)コーディネータ(スレッド)テーブルも紹介しておきます。
MySQL :: MySQL 8.0 リファレンスマニュアル :: 27.12.11.6 replication_applier_status_by_coordinator テーブル
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
SELECT * FROM performance_schema.replication_applier_status_by_coordinator\G *************************** 1. row *************************** CHANNEL_NAME: group_replication_applier THREAD_ID: 558 SERVICE_STATE: ON LAST_ERROR_NUMBER: 0 LAST_ERROR_MESSAGE: LAST_ERROR_TIMESTAMP: 0000-00-00 00:00:00.000000 LAST_PROCESSED_TRANSACTION: 1a6ca709-07ed-11ed-9526-02001702a4b7:5 LAST_PROCESSED_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP: 2022-07-20 14:31:58.497672 LAST_PROCESSED_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP: 2022-07-20 14:31:58.497672 LAST_PROCESSED_TRANSACTION_START_BUFFER_TIMESTAMP: 2022-07-20 14:31:58.497731 LAST_PROCESSED_TRANSACTION_END_BUFFER_TIMESTAMP: 2022-07-20 14:31:58.497745 PROCESSING_TRANSACTION: PROCESSING_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP: 0000-00-00 00:00:00.000000 PROCESSING_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP: 0000-00-00 00:00:00.000000 PROCESSING_TRANSACTION_START_BUFFER_TIMESTAMP: 0000-00-00 00:00:00.000000 |
なお、上記の例では表示されていませんが、分散リカバリを行う場合に group_replication_recovery というチャネルが作成されます。
監視情報の取得方法について
前置きがだいぶ長くなってしまいましたが、Group Replication の監視項目を稼働中に収集するには、上述の通り各テーブルへクエリすることになりますが、システム運用管理においてはできる限りツールを使って効率的・自動的に収集したいところです。
本記事では3つのツールでの情報取得方法を紹介します。
- MySQL Shell Admin API
- MySQL Enterprise Monitor
- Percona Monitoring and Management (PMM) 2
MySQL Shell Admin API
まずは InnoDB Cluster のコンポーネントである MySQL Shell を使う方法です。
InnoDB Cluster を構築・運用する場合のおなじみの Admin API、cluster.status() で詳細情報を取得することができ、非常に便利です。
具体的な方法は extended オプションに 1～3 の値を指定すると、取得できる情報が順に詳細になるのですが、
extended:2の場合、transactionsセクションが追加extended:3の場合、transactionsセクション内にconnection,coordinator,workersが追加
というように、非常に膨大な情報が1コマンドで得られます。
extended:3 の出力結果の抜粋を掲載しておきます。(長大になりますが内容把握の意図のためご容赦ください)
項目値の名称は多少変化していますが、前述で紹介した Group Replication に関する情報や監視項目がほぼ網羅されていることが確認できます。
JSON形式の出力項目の詳細(や対応する各テーブルのカラムなど)については、マニュアルの以下のページをご確認ください。
MySQL :: MySQL Shell 8.0 :: 6.2.3 InnoDB クラスタ の監視
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 |
# mysqlsh icadmin@127.0.0.1:3306 --execute "println(dba.getCluster().status({extended:3}))" { "clusterName": "test_cluster", "defaultReplicaSet": { "GRProtocolVersion": "8.0.27", "groupName": "1a6ca389-07ed-11ed-9526-02001702a4b7", "groupViewChangeUuid": "1a6ca709-07ed-11ed-9526-02001702a4b7", "groupViewId": "16582950451657311:7", "name": "default", "primary": "gr-mysql-e1:3306", "ssl": "REQUIRED", "status": "OK", "statusText": "Cluster is ONLINE and can tolerate up to ONE failure.", "topology": { "gr-mysql-e1:3306": { "address": "gr-mysql-e1:3306", "applierWorkerThreads": 4, "fenceSysVars": [], "memberId": "c0644108-07ec-11ed-8f49-02001702a4b7", "memberRole": "PRIMARY", "memberState": "ONLINE", "mode": "R/W", "readReplicas": {}, "replicationLag": null, "role": "HA", "status": "ONLINE", "transactions": { "appliedCount": 5, "checkedCount": 2720, "committedAllMembers": "1a6ca389-07ed-11ed-9526-02001702a4b7:1-2714,1a6ca709-07ed-11ed-9526-02001702a4b7:1-5,c0644108-07ec-11ed-8f49-02001702a4b7:1", "conflictsDetectedCount": 0, "connection": { "lastHeartbeatTimestamp": "", "lastQueued": { "endTimestamp": "2022-07-20 14:31:58.497711", "immediateCommitTimestamp": "2022-07-20 14:31:58.497672", "immediateCommitToEndTime": 0.000039, "originalCommitTimestamp": "2022-07-20 14:31:58.497672", "originalCommitToEndTime": 0.000039, "queueTime": 0.000013, "startTimestamp": "2022-07-20 14:31:58.497698", "transaction": "1a6ca709-07ed-11ed-9526-02001702a4b7:5" }, "receivedHeartbeats": 0, "receivedTransactionSet": "1a6ca389-07ed-11ed-9526-02001702a4b7:1-2719,1a6ca709-07ed-11ed-9526-02001702a4b7:1-5,c0644108-07ec-11ed-8f49-02001702a4b7:1", "threadId": null }, "coordinator": { "lastProcessed": { "bufferTime": 0.000014, "endTimestamp": "2022-07-20 14:31:58.497745", "immediateCommitTimestamp": "2022-07-20 14:31:58.497672", "immediateCommitToEndTime": 0.000073, "originalCommitTimestamp": "2022-07-20 14:31:58.497672", "originalCommitToEndTime": 0.000073, "startTimestamp": "2022-07-20 14:31:58.497731", "transaction": "1a6ca709-07ed-11ed-9526-02001702a4b7:5" }, "threadId": 558 }, "inApplierQueueCount": 0, "inQueueCount": 0, "lastConflictFree": "1a6ca389-07ed-11ed-9526-02001702a4b7:2720", "proposedCount": 2720, "rollbackCount": 0, "workers": [ { "lastApplied": { "applyTime": 0.001136, "endTimestamp": "2022-07-20 14:31:58.498891", "immediateCommitTimestamp": "2022-07-20 14:31:58.497672", "immediateCommitToEndTime": 0.001219, "originalCommitTimestamp": "2022-07-20 14:31:58.497672", "originalCommitToEndTime": 0.001219, "retries": 0, "startTimestamp": "2022-07-20 14:31:58.497755", "transaction": "1a6ca709-07ed-11ed-9526-02001702a4b7:5" }, "threadId": 559 }, /** 以降ワーカースレッド分出力続く**/ ] }, /** 以降、グループメンバー分出力続く**/ }, "topologyMode": "Single-Primary" }, "groupInformationSourceMember": "gr-mysql-e1:3306", "metadataVersion": "2.1.0" } |
この API を使用して定期的に JSON データとして取得し、別途ログ解析ツールなどで可視化や情報整理、分析を行うのが良いと思います。
MySQL Enterprise Monitor
MySQL Enterprise Monitor は2025年1月1日に EOL を迎えたため、
以降は新規バグ修正や新規セキュリティ修正、新機能開発等が行われません。
詳細は以下をご参照ください。
MySQL :: MySQL Enterprise Monitor 8.0 Manual :: 1 MySQL Enterprise Monitor: End of Life Notice
MySQL Enterprise Monitor の EOL と Oracle Enterprise Manager for MySQL の紹介 | スマートスタイル TECH BLOG
MySQL Enterprise Edition をご利用の場合は、MySQL Enterprise Monitor(MEM) を利用するのが最も推奨される選択肢となります。
通常のレプリケーションだけでなく、Group Replication の監視にも対応しています。
MySQL :: MySQL Enterprise Monitor 8.0 Manual :: 27 Replication Dashboard
Agent を導入せずともリモート監視方式でも Group Replication 情報を収集することが可能です。(Agent 監視ではホストリソースも収集できるため総合的な観点では導入を推奨します)
Group Replication に関する実際の情報表示画面をご紹介します。(MySQL Commercial Server 8.0.29 / MEM 8.0.30 を使用)
トポロジー
レプリケーション
MEM の特徴としては、バイナリログに関する情報や Group Replication 関連パラメータの一覧があることで、状態把握のしやすさに長けています。
また、プリセットされているアドバイザ(定期監視項目の設定)では、グループレプリケーション構成 と グループレプリケーションステータス という2つが用意されています。
MySQL :: MySQL Enterprise Monitor 8.0 Manual :: 20.11 Group Replication Advisors
group_replication_* パラメータのうち、変更されたことで構成に影響を及ぼすものについてアラートを生成するようにしたり、レプリケーショントポロジー上の状態の変化(メンバーダウンによる可用性の低下)などをアラート通知するようになっています。
ローカライゼーションだったり、グラフの見やすさといったUIの面でもおすすめのツールです。
Percona Monitoring and Management (PMM) 2
過去ブログ記事でも紹介していますが、MySQL Group Replication Summary ダッシュボードが PMM 2.10.0 から追加され、標準で使用可能です。
Percona Monitoring and Managementの新機能の紹介 | スマートスタイル TECH BLOG
改めてこのダッシュボードで確認できる項目(グラフ)を、今回は PMM 2.28.0 を使用して紹介します。
こちらも、Agentをインストールせずともリモート監視方式で Group Replication 情報を収集できます。
参考記事：Percona Monitoring and Management 2 を使用したリモートインスタンスの監視 | スマートスタイル TECH BLOG
各メトリクスの収集クエリは PMM Server 内の以下の YAML ファイルで定義されているので、こちらを覗いてみましょう。
|
1 |
/usr/local/percona/pmm2/collectors/custom-queries/mysql/high-resolution/queries-mysqld-group-replication.yml |
※ YAML 内の _5 サフィックスのある定義は 5.7 用、サフィックス無しは 8.0 用です。
Overview
performance_schema.replication_group_members テーブルから以下のクエリで収集した情報が表示されます。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
SELECT CHANNEL_NAME AS channel_name , MEMBER_ID AS member_id , MEMBER_HOST AS member_host , MEMBER_PORT AS member_port , MEMBER_STATE AS member_state , MEMBER_ROLE AS member_role , MEMBER_VERSION AS member_version , CASE WHEN MEMBER_STATE = 'ONLINE' THEN 1 WHEN MEMBER_STATE = 'RECOVERING' THEN 2 WHEN MEMBER_STATE = 'OFFLINE' THEN 3 WHEN MEMBER_STATE = 'ERROR' THEN 4 WHEN MEMBER_STATE = 'UNREACHABLE' THEN 5 END AS member_info FROM performance_schema.replication_group_members WHERE MEMBER_ID = @@server_uuid; |
Replication Delay Details
以下のクエリで収集した情報のグラフです。
主に replication_applier_status_by_worker テーブルのタイムスタンプカラムから算出されています。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
SELECT conn_status.channel_name AS channel_name , conn_status.service_state AS IO_thread , applier_status.service_state AS SQL_thread , LAST_APPLIED_TRANSACTION_END_APPLY_TIMESTAMP - LAST_APPLIED_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP 'rep_delay_seconds' , LAST_QUEUED_TRANSACTION_START_QUEUE_TIMESTAMP - LAST_QUEUED_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP 'transport_time_seconds' , LAST_QUEUED_TRANSACTION_END_QUEUE_TIMESTAMP - LAST_QUEUED_TRANSACTION_START_QUEUE_TIMESTAMP 'time_RL_seconds' , LAST_APPLIED_TRANSACTION_END_APPLY_TIMESTAMP - LAST_APPLIED_TRANSACTION_START_APPLY_TIMESTAMP 'apply_time_seconds' , IF(GTID_SUBTRACT( LAST_QUEUED_TRANSACTION,LAST_APPLIED_TRANSACTION)='','0', ABS(TIME_TO_SEC( IF(TIME_TO_SEC(APPLYING_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP)=0,0, TIMEDIFF(APPLYING_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP,NOW()) ) )) ) <code>lag_in_seconds FROM performance_schema.replication_connection_status AS conn_status JOIN performance_schema.replication_applier_status_by_worker AS applier_status ON applier_status.channel_name = conn_status.channel_name WHERE conn_status.service_state = 'ON' ORDER BY lag_in_seconds , lag_in_seconds desc; |
| グラフ名 | クエリのSELECTカラム別名 |
|---|---|
| Replication Lag | lag_in_seconds |
| Transport Time | transport_time_seconds |
| Replication Delay | rep_delay_seconds |
| Transaction Apply Time | apply_time_seconds |
| Transaction Time Inside the Local Queue | time_RL_seconds |
Transactions, Conflicts
Transancitons セクションでは前述の適用トランザクションキューイング数の推移をグラフで確認できます。
|
1 2 3 4 5 6 7 8 9 10 |
SELECT COUNT_TRANSACTIONS_IN_QUEUE AS transactions_in_queue , COUNT_TRANSACTIONS_CHECKED AS transactions_checked_total , COUNT_CONFLICTS_DETECTED AS conflicts_detected_total , COUNT_TRANSACTIONS_ROWS_VALIDATING AS transactions_rows_validating_total , COUNT_TRANSACTIONS_REMOTE_IN_APPLIER_QUEUE AS transactions_remote_in_applier_queue , COUNT_TRANSACTIONS_REMOTE_APPLIED AS transactions_remote_applied_total , COUNT_TRANSACTIONS_LOCAL_PROPOSED AS transactions_local_proposed_total , COUNT_TRANSACTIONS_LOCAL_ROLLBACK AS transactions_local_rollback_total FROM performance_schema.replication_group_member_stats WHERE MEMBER_ID = @@server_uuid; |
| グラフ名 | クエリのSELECTカラム別名 |
|---|---|
| Checked Transactions | transactions_checked_total |
| Transactions Row Validating | transactions_rows_validating_total |
| Applied Transactions | transactions_remote_applied_total |
| Sent Transactions | transactions_local_proposed_total |
| Received Transactions Queue | transactions_remote_in_applier_queue |
| Rolled Back Transactions | transactions_local_rollback_total |
| Transactions in the Queue for Checking | transactions_in_queue |
| Detected Conflicts | conflicts_detected_total |
※Transactions Details の情報は 前述 Replication Delay Details に載せたクエリで取得される IO_thread,SQL_thread,last_queued_transaction,last_applied_transaction といった情報が最新から降順で一覧表示されます。
MySQL Routerの監視は？
InnoDB Cluster という観点では MySQL Router の監視も行ったほうがよりよい運用と言えます。
ただ、残念ながらMySQL Router を監視できるツールは上述のツールのみならず現在無いのですが、ちょうど先週公開された以下の弊社過去ブログ記事の方法を使用・応用することをおすすめします。(REST API 使用可能な監視ツールと連携させて情報取得できるようにする、など)
REST API を使用した MySQL Router のステータス確認方法 | スマートスタイル TECH BLOG
まとめ
今回の記事では、Group Replication の監視に必要な情報が取得できるパフォーマンススキーマ各テーブルと、Group Replication 監視が標準で実装されている主要なMySQL専用監視ツール MySQL Enterprise Monitor, PMM2 について紹介しました。
MySQL Shell Admin API(cluster.status)を使って自力で取得するのでも情報の粒度という観点では問題はないですが、取得後のデータの可視化や分析にどうしても手間がかかってしまうので、長期的な運用が見込まれるのであれば監視ツールを早めに導入しておくのが望ましいです。
MySQL Enterprise Editon ユーザであれば MySQL Enterprise Monitor 一択かと思います。
Community Edition や Percona Server for MySQL ユーザでしたら PMM2 は 豊富な監視機能を有していておすすめの監視ツールです。
もしくは、既存で使用中の監視ツールがユーザ定義のカスタムメトリクスを追加できるのであれば、PMM2の紹介の箇所で載せてあるクエリを参考に監視設定を自作する、という方法もあります。
InnoDB Cluster に移行したけど、監視がまだできていない、とお悩みの場合もぜひ本記事を参考にしていただけると幸いです。
