以前のブログ投稿では、MySQLかMariaDBかに関係なく、Galeraクラスターを監視するためのトピックについて説明しました。テクノロジーのバージョンに大きな違いはありませんが、MariaDBクラスターにはバージョン10.4.2からいくつかの大きな変更があります。このバージョンでは、Galera Cluster 4をサポートし、このブログ投稿で説明するいくつかの優れた新機能を備えています。
MariaDBクラスターにまだ慣れていない初心者向けの、MariaDB用の仮想同期マルチマスタークラスターです。 Linuxでのみ使用可能で、XtraDB / InnoDBストレージエンジンのみをサポートします（ただし、MyISAMは実験的にサポートされています。wsrep_replicate_myisamシステム変数を参照してください）。
このソフトウェアは、MariaDBサーバー、Codership（UnixライクなOSをサポート）によって開発されたMySQLサーバーとMariaDBサーバー用のMySQL-wsrepパッチ、およびGalerawsrepプロバイダーライブラリを利用したバンドルテクノロジーです。
この製品を、MySQLGroupReplicationまたは高可用性の提供を目的としたMySQLInnoDBClusterと比較することができます。 （ただし、HAを提供するための原則とアプローチはさまざまです。）
これで基本事項について説明したので、このブログでは、MariaDBクラスターを監視するときに役立つと思われるヒントを提供します。
MariaDBクラスターの要点
MariaDBクラスターの使用を開始するときは、目的が正確に何であるか、そして最初にMariaDBクラスターを選択した理由を特定する必要があります。まず、MariaDBクラスターを使用する際の機能とその利点を理解する必要があります。これらを特定する理由は、パフォーマンス、通常の健康状態、および計画どおりに実行されているかどうかを判断するために、基本的にこれらを監視およびチェックする必要があるためです。
基本的に、スレーブラグ、トランザクションの損失、読み取りスケーラビリティ、およびクライアントの待機時間の短縮はありません。次に、どのようにしてスレーブの遅延やトランザクションの損失を発生させないのかなどの質問が発生する可能性があります。どのようにして読み取りをスケーラブルにしたり、クライアント側のレイテンシーを小さくしたりしますか？これらの領域は、特に大量の本番環境で使用する場合に確認および監視する必要がある重要な領域の1つです。
ただし、MariaDBクラスター自体はそれに応じてカスタマイズできます。 pc.weightやpc.ignore_quorumなどのデフォルトの動作に変更を適用したり、多数のノードにUDPでマルチキャストを使用したりすると、MariaDBクラスターの性質を監視する方法に影響を与える可能性があります。しかし一方で、最も重要なステータス変数は通常、クラスターの状態とフローが正常に機能しているか、劣化していることを知っているここでの銀色の裏地であり、壊滅的な障害につながる可能性のある問題を事前に示しています。
サーバーアクティビティ（ネットワーク、ディスク、ロード、メモリ、CPU）を常に監視する
データベースアーキテクチャに非常に複雑なスタックが絡み合っている場合、サーバーアクティビティの監視も複雑な作業になる可能性があります。ただし、MariaDBクラスターの場合は、ノードを常に専用でありながら可能な限りシンプルにセットアップすることが常に最善です。すべての予備のリソースを使用することを制限するものではありませんが、以下は、調査する必要のある一般的な重要な領域です。
Galera Cluster 4は、主要な機能の1つとしてストリーミングレプリケーションを備えており、以前のバージョンから変更されています。ストリーミングレプリケーションは以前のリリースでの欠点に対処しますが、Galera Cluster 4以降の2GBを超える書き込みセットを管理できるため、大きなトランザクションを断片化できるため、セッションレベルでのみこれを有効にすることを強くお勧めします。つまり、ネットワークアクティビティを監視することは、MariaDBクラスターの通常のアクティビティにとって非常に重要で重要です。これは、期間に基づいて、どのノードが最大または最大のネットワークトラフィックを持っていたかを特定するのに役立ちます。
では、ネットワークトラフィックが最も多いノードが特定された場所を改善するにはどうすればよいでしょうか。これにより、データベーストポロジまたはデータベースクラスターのアーキテクチャーレイヤーを改善する余地が生まれます。ロードバランサーまたはデータベースプロキシを使用すると、特にどの特定の書き込みを特定のノードに送信するかを決定するときに、データベーストラフィックを事前に構成できます。たとえば、3つのノードのうち、ハードウェアの仕様が異なるため、そのうちの1つは大規模なクエリと大きなクエリを処理する能力が高いとしましょう。これにより、特定の期間の需要の変化に応じて、より多くの設備投資を管理し、キャパシティプランニングを改善できます。
ネットワークアクティビティは、特にフラッシュ時間中のディスクパフォーマンスにも影響するため。また、高いピーク負荷に達したときにコミットされた時間と取得がどのように実行されるかを判断することも最適です。 Galera Clusterアクティビティ専用であるだけでなく、docker、ProxySQLやMaxScaleなどのSQLプロキシなどの他のツールとマッシュアップすることで、データベースホストをストックする場合があります。これにより、低負荷のサーバーで制御できるようになり、特にデータベースアーキテクチャスタックにとって他の有益な目的に利用できる予備のリソースを使用できるようになります。監視時にどのノードの負荷が最も低いかを判断でき、ディスクIO使用率を管理できるようになったら、時間の経過を監視しながら特定のノードを選択できます。繰り返しになりますが、これにより、キャパシティプランニングでより適切な管理が可能になります。
CPU、メモリ、およびロードアクティビティ
監視する際に注意すべき、これら3つの領域について簡単に説明します。このセクションでは、次の領域を一度に観察しやすくすることが常に最善です。特に、パフォーマンスのボトルネックを排除したり、ノードを停止させたり、他のノードやクラスターをダウンさせる可能性に影響を与える可能性のあるバグを特定したりする方が、すばやく簡単に理解できます。
では、監視時のCPU、メモリ、および負荷のアクティビティは、MariaDBクラスターにどのように役立ちますか？さて、私が上で述べたように、それらは毎日の定期的なチェックのための数少ないものの1つですが大きな要因です。さて、これは、これらが定期的またはランダムに発生するかどうかを識別するのにも役立ちます。定期的な場合は、Galeraノードの1つで実行されているバックアップに関連している可能性があります。または、最適化が必要な大規模なクエリです。たとえば、適切なインデックスがない不正なクエリや、このような大きな文字列の文字列比較を行うなど、データ取得の使用のバランスが崩れています。これは、MariaDB ClusterなどのOLTPタイプのデータベースには、特にそれが実際にアプリケーションの性質と要件である場合は、間違いなく適用できない可能性があります。大きな文字列データの取得や文字列の照合には、MariaDB Columnstoreなどの他の分析ツール、または他のサードパーティの分析処理ツール（Apache Spark、Kafka、MongoDBなど）を使用することをお勧めします。
これらすべての重要な領域が監視されているので、問題は、それをどのように監視するかということです。少なくとも1分ごとに監視する必要があります。洗練された監視を使用すると、つまり、1秒あたりの集合的なメトリックはリソースを大量に消費し、リソースに関して非常に貪欲になる可能性があります。特にデータとRPO（目標復旧時点）が非常に低い場合は、30分の収集が許容されますが、より詳細でリアルタイムのデータメトリックが必要です。データベースクラスターの全体像を監視できることが非常に重要です。これとは別に、監視しているメトリックがいつでも、物事が危険にさらされているとき、または単なる警告でさえも注意を引くための適切なツールを持っていることも最善かつ重要です。 ClusterControlなどの適切なツールを使用すると、監視対象のこれらの重要な領域を管理するのに役立ちます。ここでは、ClusterControlの無料バージョンまたはコミュニティエディションを使用しており、数回クリックするだけで、インストールからノードの監視まで、面倒なことなくノードを監視できます。たとえば、以下のスクリーンショットを参照してください。
ビューは、現在起こっていることのより洗練された迅速な概要です。より詳細なグラフも使用できます
または、クエリ言語もサポートするより強力で豊富なデータモデルを使用してタイムリーにパフォーマンスを比較する履歴データに基づいて、MariaDBクラスターのパフォーマンスの分析を提供します。たとえば、
これにより、より目に見える指標が提供されます。したがって、MariaDBクラスターを監視するときに適切なツールを使用することが本当に重要であることがわかります。
MariaDBクラスター統計変数の集合的な監視を確実にする
時折、MariaDBクラスターのバージョンが、より多くのステータス変数を提供し、監視する値を調整することで、データベースの監視の性質を監視または強化するための新しい統計を生成することは避けられません。上で述べたように、このサンプルブログでは、ClusterControlを使用してノードを監視しています。しかし、それはそれがそこにある最高のツールであるという意味ではありません。つまり、PerconaのPMMは、すべての統計変数の集合的な監視に関して非常に豊富であり、MariaDBクラスターが提供する新しい統計変数がある場合はいつでも、PMMはオープンソースツールであるため、これを活用して変更することができます。特に、毎分数十万のリクエストに対応する本番ベースのデータベースでは、あらゆる側面が重要であるため、MariaDBクラスターのすべての可視性を備えていることは大きな利点です。
しかし、ここで問題をより具体的に見ていきましょう。調べるべきこれらの統計変数は何ですか？ MariaDBクラスターには多くのメリットがありますが、MariaDBクラスターが提供するものを使用すると思われる機能と利点に再び焦点を当て、それに焦点を当てます。
MariaDBクラスターのフロー制御は、クラスター全体でレプリケーションの正常性がどのように実行されるかについての概要を提供します。 Galera Clusterのレプリケーションプロセスはフィードバックメカニズムを使用します。つまり、そのクラスター内のノード全体に信号を送り、ノードが必要に応じてレプリケーションを一時停止または再開する必要があるかどうかにフラグを立てます。これにより、他のノードが着信トランザクションを適用しているときに、ノードの遅延が大きくなりすぎるのを防ぐこともできます。これは、フロー制御がガレラ内でその機能として機能する方法です。ここで、MariaDBクラスターを監視するときに、これを確認し、見落とさないようにする必要があります。これは、MariaDBクラスターを使用する利点の1つで述べたように、スレーブの遅延を回避できることです。これはフロー制御とスレーブラグについて理解するにはあまりにも単純ですが、フロー制御を使用すると、キューが多く、ディスクへのページのコミットまたはフラッシュが非常に低くなると、Galeraクラスターのパフォーマンスに影響を与えます。実行中のクエリが悪いクエリであるだけです。 Galeraの仕組みの初心者であれば、Galeraのフロー制御とは何かについてのこの外部投稿を読むことに興味があるかもしれません。
送信または受信されたバイトは、ネットワーキングアクティビティと相関関係があり、フロー制御と並べて表示する重要な領域の1つです。これにより、Galeraクラスター内で発生しているパフォーマンスの問題に最も影響を与えているノードまたは原因となっているノードを特定できます。ダーティページの同期に時間がかかりすぎる可能性のあるネットワークデバイスや基盤となるストレージデバイスなどのハードウェアに劣化がないかどうかを確認できるため、非常に重要です。
これは、サーバーの稼働時間以降にこれまでにクエリまたはデータ取得が行われた量のデータベースアクティビティの詳細です。これは、データベースクラスターのパフォーマンスに主に影響を与えているクエリの種類を除外するのに役立ちます。これにより、特にデータベース要求の負荷のバランスをとる上で改善の余地を提供できます。 ProxySQLを使用すると、クエリルーティングのより洗練されたきめ細かいアプローチが可能になります。 MaxScaleもこの機能を提供しますが、ProxySQLの粒度は高くなりますが、パフォーマンスへの影響やコストも発生します。クエリルーティングを実行するSQLプロキシとしてProxySQLが1つしかない場合に影響があり、トラフィックが多い場合は問題が発生する可能性があります。基盤となるKeepAlivedのトラフィックのバランスをとるために、ProxySQLノードを追加すると、コストがかかります。これは完璧なコンボですが、必要になるまで低コストで実行できます。しかし、必要かどうかをどのように判断できますか？それがここに残っている問題なので、これらの重要な領域を監視する鋭い目は、可観測性だけでなく、時間の経過とともにデータベースクラスターのパフォーマンスを向上させるためにも非常に重要です。
そのため、MariaDBクラスターで確認する変数はたくさんあります。ここで考慮しなければならない最も重要なことは、データベースクラスターの監視に使用しているツールです。前述のように、このブログではClusterControl（Community Edition）の無料バージョンライセンスを使用することをお勧めします。これにより、GaleraClusterで柔軟に検討できる方法が増えます。以下の例を参照してください
視覚的に監視できるタブを赤でマークまたは丸で囲んでいますMariaDBクラスターの状態。たとえば、アプリケーションがストリーミングレプリケーションの使用に貪欲であり、クラスターの対話性のために多数のフラグメント（大規模なネットワーク転送）を送信する場合は、ノードがストレスをどれだけうまく処理できるかを判断するのが最善です。特に、アプリケーションに特定の変更を加える前のストレステストでは、アプリケーション製品の容量管理を判断し、現在のデータベースノードと設計がアプリケーション要件の負荷を処理できるかどうかを判断するためにテストを行うのが常に最善です。
ClusterControlのコミュニティエディションでも、MariaDBクラスターの正常性に関するより詳細で洗練された結果を収集できます。以下を参照してください
これは、MariaDBクラスターの監視にアプローチする方法です。完璧な視覚化は、常に管理がより簡単で迅速です。事態が悪化すると、生産性を失うわけにはいきません。また、ダウンタイムがビジネスに影響を与える可能性があります。無料であるからといって、トラフィックの多いデータベースを管理する際の贅沢さと快適さは得られませんが、1つの領域でアラーム、通知、およびデータベース管理を行うことは、ClusterControlが実行できるウォークインザパークアドオンです。
MariaDBクラスターは、従来の非同期MySQL / MariaDBマスタースレーブセットアップと比較して、監視が簡単ではありません。動作が異なり、データベースクラスターで何が起こっているのか、何が起こっているのかを判断するための適切なツールが必要です。事前に適切な監視を行わずにMariaDBクラスターを実行する前に、必ず事前に容量計画を準備してください。壊滅的なイベントが発生する前に、データベースの負荷とアクティビティを把握しておくことが常に最善です。