InnoDB Cluster・Group Replication の監視方法について

この記事は最終更新から2年以上経過しています。内容が古くなっている可能性があります。

今回は、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,ホスト名,ステータス,クラスタロール,バージョン)が確認できます。

グループの全体状況を確認する際に参照することが多いと思います。

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)が確認できます。

確認クエリの例

以下は、各メンバーの適用トランザクションキューイング数を取得するクエリの例です。
replication_group_member_stats テーブルではメンバーを識別できるカラムが MEMBER_ID のみで分かり辛いため、replication_group_members と結合して表示しています。

各キューイング数が以下の条件で閾値超過した場合 Group Replication のフローコントロールが発動しプライマリ(ライター)ノードで更新処理のスロットルが発生しますので、パフォーマンス観点での重要な監視項目と言えます。

  • COUNT_TRANSACTIONS_IN_QUEUEgroup_replication_flow_control_certifier_threshold パラメータ(デフォルト:25,000)よりも大きい場合
  • COUNT_TRANSACTIONS_REMOTE_IN_APPLIER_QUEUEgroup_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 には、グループから受信してアプライヤキュー (リレーログ) にキューに入れられたトランザクションなど、グループレプリケーションに関する情報が表示されます。

performance_schema.replication_applier_status

MySQL :: MySQL 8.0 リファレンスマニュアル :: 27.12.11.5 replication_applier_status テーブル

performance_schema.replication_applier_status には、Group Replication 関連のチャネルおよびスレッドの状態が表示されます。トランザクションを適用するワーカースレッドが多数ある場合は、ワーカーテーブルを使用して、各ワーカースレッドの実行内容を監視することもできます。

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 で指定したスレッド数分、情報が表示されます。

performance_schema.replication_applier_status_by_coordinator

もう一つ、(前後しますが)コーディネータ(スレッド)テーブルも紹介しておきます。

MySQL :: MySQL 8.0 リファレンスマニュアル :: 27.12.11.6 replication_applier_status_by_coordinator テーブル

なお、上記の例では表示されていませんが、分散リカバリを行う場合に 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 クラスタ の監視

この API を使用して定期的に JSON データとして取得し、別途ログ解析ツールなどで可視化や情報整理、分析を行うのが良いと思います。

MySQL Enterprise Monitor

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 ファイルで定義されているので、こちらを覗いてみましょう。

※ YAML 内の _5 サフィックスのある定義は 5.7 用、サフィックス無しは 8.0 用です。

Overview

performance_schema.replication_group_members テーブルから以下のクエリで収集した情報が表示されます。

Replication Delay Details

以下のクエリで収集した情報のグラフです。

主に replication_applier_status_by_worker テーブルのタイムスタンプカラムから算出されています。

グラフ名 クエリの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 セクションでは前述の適用トランザクションキューイング数の推移をグラフで確認できます。

グラフ名 クエリの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 に移行したけど、監視がまだできていない、とお悩みの場合もぜひ本記事を参考にしていただけると幸いです。

スマートスタイルTECHブログについて

スマートスタイルTECHブログでは、日頃MySQLのサポート業務に従事している有資格者で構成された技術サポートチームがMySQLに関する技術情報を発信しています。データベースのお困りごとはお気軽にご相談下さい。

スマートスタイルTECHブログについて

スマートスタイルTECHブログでは、日頃オープンソースデータベースのサポート業務に従事している有資格者で構成された技術サポートチームがPerconaに関する技術情報を発信しています。データベースのお困りごとはお気軽にご相談下さい。

よかったらシェアしてね!
  • URLをコピーしました!
目次