Percona XtraDB Clusterは、MySQLの世界で非常によく知られている高可用性ソリューションです。これはGaleraClusterに基づいており、複数のノード間で実質的に同期レプリケーションを提供します。すべてのデータベースと同様に、パフォーマンスが期待されるレベルにある場合はシステムで何が起こっているかを追跡し、そうでない場合はボトルネックを追跡することが重要です。これは、パフォーマンスが影響を受ける状況で適切に対応できるようにするために最も重要です。もちろん、Percona XtraDB Clusterには複数のメトリックが付属しており、データベースの状態を追跡するために最も重要なメトリックがどれであるかが常に明確であるとは限りません。このブログでは、PXCを使用する際に注目したいいくつかの主要な指標について説明します。
明確にするために、PXCとGaleraに固有のメトリックに焦点を当てますが、MySQLまたはInnoDBのメトリックについては説明しません。これらの指標については、以前のブログで説明されています。
PXCが私たちに提示する最も重要な情報のいくつかを見てみましょう。
フロー制御は、Galera Clusterで監視できる最も重要な指標であるため、少し背景を説明しましょう。 Galeraは、マルチマスターの仮想同期クラスターです。それを形成する任意のデータベースノードで書き込みを実行することが可能です。すべての書き込みは、クラスター内のすべてのノードに送信して、確実に適用できるようにする必要があります。このプロセスは、認証と呼ばれます。すべてのノードがコミットできることに同意するまで、トランザクションを適用することはできません。いずれかのノードにトラフィックに対応できないパフォーマンスの問題がある場合、ノードはフロー制御メッセージの発行を開始します。これは、クラスターの残りの部分にパフォーマンスの問題を通知し、ワークロードを減らして遅延を支援するように依頼することを目的としています。クラスターの残りの部分に追いつくためのノード。
フロー制御の一時停止メトリック（wsrep_flow_control_paused）を使用して、ノードが遅れているピアに追いつくために人為的な一時停止を導入する必要があった時期を追跡できます。
ノードがフロー制御メッセージを送信しているか受信しているかを追跡することもできます（wsrep_flow_control_recvおよびwsrep_flow_control_sent）。
この情報は、どのノードが同じ上で実行されていないかをよりよく理解するのに役立ちますその仲間としてのレベル。次に、そのノードに焦点を合わせて、問題の内容とボトルネックを取り除く方法を理解してみてください。
これらのメトリックは、フロー制御に関連しているようなものです。すでに説明したように、ノードがクラスター内の他のノードより遅れている可能性があります。これは、ワークロードが不均一に分割されているか、その他の理由（バックグラウンドで実行されているプロセス、バックアップ、またはカスタムの重いクエリ）が原因である可能性があります。フロー制御が開始される前に、遅延ノードは、パフォーマンスへの影響が一時的であり、すぐに追いつくことができることを期待して、受信キュー（wsrep_local_recv_queue）に着信書き込みセットを格納しようとします。キューが大きくなりすぎた場合（gcs.fc_limit設定によって管理されます）にのみ、フロー制御メッセージがクラスター全体に送信され始めます。
受信キューは、そこにあることを示す初期のマーカーと考えることができます。パフォーマンスに問題があり、フロー制御が開始される可能性があります。
一方、送信キュー（wsrep_local_send_queue）は、ノードがクラスターの他のメンバーに書き込みセットを送信できないことを通知します。これは、ネットワーク接続の問題を示している可能性があります（書き込みセットをネットワークは実際にはリソースを大量に消費しません。
Percona XtraDBクラスターは、複数のスレッドを使用して着信書き込みセットを適用するように構成できます。これにより、クラスターに接続し、同時に書き込みを発行する複数のスレッドをより適切に処理できます。注目すべき主な指標は2つあります。
最初に、wsrep_cert_deps_distanceは、並列化の可能性、つまり同時に適用できる書き込みセットの数を示します。この値に基づいて、着信書き込みセットの適用で機能する並列スレーブスレッド（wsrep_slave_threads）の数を構成できます。経験則では、wsrep_cert_deps_distanceの値よりも多くのスレッドを構成しても意味がありません。
一方、2番目のメトリックは、ライトセットを適用するプロセスをどれだけ効率的に並列化できたかを示します-wsrep_apply_oooeは、アプライヤーがライトセットを順不同で適用し始めた頻度を示します（これは、より良い並列化を示します） 。
ご覧のとおり、PerconaXtraDBClusterで確認する価値のあるメトリックがいくつかあります。もちろん、このブログの冒頭で述べたように、これらはPXCとGaleraCluster一般に厳密に関連するメトリックです。
また、データベースの状態をよりよく理解するために、通常のMySQLおよびInnoDBメトリックにも注意を払う必要があります。また、ClusterControlCommunityEditionを使用してこのテクノロジーを無料で監視できることを忘れないでください。