前の2つのブログ投稿では、4種類のクラスタリング/レプリケーション（MySQL / Galera、MySQLレプリケーション、MongoDB、PostgreSQL）のデプロイと、既存のデータベースとクラスターの管理/監視の両方について説明しました。したがって、これら2つの最初のブログ投稿を読んだ後、既存の20のレプリケーション設定をClusterControlに追加し、それらを拡張し、さらに2つの新しいGaleraクラスターを展開すると同時に他の多くのことを行うことができました。または、MongoDBやPostgreSQLシステムをデプロイしたかもしれません。では、どうやって彼らを健康に保つのですか？
これがまさにこのブログ投稿の内容です。ClusterControlパフォーマンスモニタリングおよびアドバイザ機能を活用して、MySQL、MongoDB、PostgreSQLデータベースおよびクラスターを正常に保つ方法です。では、これはClusterControlでどのように行われますか？
データベースクラスターリスト
最も重要な情報は、クラスターリストに既にあります。アラームがなく、ホストがダウンしていることが示されていない限り、すべてが正常に機能しています。特定の条件が満たされた場合、アラームが発生します。ホストがスワップしているため、調査する必要のある問題に注意が向けられます。つまり、停止中にアラームが発生するだけでなく、データベースをプロアクティブに管理できるようになります。
ClusterControlにログインして、次のようなクラスターリストを表示するとします。たとえば、Galeraクラスターで1つのノードがダウンしていて、すべてのクラスターにさまざまなアラームがあります。
アラームの1つをクリックすると、クラスターのすべてのアラームの詳細ページに移動します。アラームの詳細は問題を説明し、ほとんどの場合、問題を解決するためのアクションもアドバイスします。
カスタム式を作成して独自のアラームを設定できますが、カスタムJavascriptを記述してアドバイザとして実行できる新しいDeveloper Studioが採用され、廃止されました。この投稿の後半でこのトピックに戻ります。
クラスターの概要-ダッシュボード
クラスタの概要を開くと、タブにクラスタの最も重要なパフォーマンスメトリックがすぐに表示されます。この概要は、クラスタータイプごとに異なる場合があります。たとえば、Galeraには、従来のMySQL、PostgreSQL、またはMongoDBとは異なるパフォーマンスメトリックがあります。
デフォルトの概要と事前に選択されたタブの両方をカスタマイズできます。 [概要]->[ダッシュ設定]をクリックします。 ダッシュボードを定義するためのダイアログが表示されます：
プラス記号を押すと、ダッシュボードをグラフ化するための独自のメトリックを追加および定義できます。この例では、Galera固有の送受信キューの平均を特徴とする新しいダッシュボードを定義します。
この新しいダッシュボードは、Galeraクラスターの平均キュー長に関する優れた洞察を提供するはずです。
[保存]を押すと、このクラスターで新しいダッシュボードが利用できるようになります：
同様に、PostgreSQLでもこれを行うことができます。たとえば、ヒットした共有ブロックと読み取ったブロックを監視できます。
ご覧のとおり、独自の（デフォルトの）ダッシュボードを比較的簡単にカスタマイズできます。
クラスターの概要-クエリモニター
[クエリモニター]タブは、MySQLベースとPostgreSQLベースの両方のセットアップで使用でき、上位クエリ、実行中クエリ、クエリ外れ値の3つのダッシュボードで構成されています。
実行中のクエリダッシュボードには、実行中の現在のすべてのクエリが表示されます。これは基本的に、MySQLデータベースのSHOWFULLPROCESSLISTステートメントと同等です。
上位のクエリとクエリの外れ値はどちらも、低速のクエリログまたはパフォーマンススキーマの入力に依存しています。パフォーマンススキーマの使用は常に推奨されており、有効にすると自動的に使用されます。それ以外の場合、ClusterControlはMySQLの低速クエリログを使用して実行中のクエリをキャプチャします。 ClusterControlが煩わしくなりすぎて、遅いクエリログが大きくなりすぎないようにするために、ClusterControlは、遅いクエリログをオンまたはオフにしてサンプリングします。このループは、デフォルトで1秒のキャプチャと long_query_timeに設定されています。 0.5秒に設定されています。クラスタのこれらの設定を変更する場合は、[設定]->[クエリモニター]を使用して変更できます。 。
トップクエリは、その名前が示すように、サンプリングされたトップクエリを表示します。頻度、平均実行時間、合計実行時間、標準偏差時間など、さまざまな列で並べ替えることができます。
クエリを選択すると、クエリの詳細を取得できます。これにより、クエリ実行プラン（利用可能な場合）と最適化のヒント/アドバイスが表示されます。クエリの外れ値は上位のクエリに似ていますが、ホストごとにクエリをフィルタリングして、時間内に比較することができます。
クラスターの概要-操作
PostgreSQLおよびMySQLシステムと同様に、MongoDBクラスターには操作の概要があり、MySQLの実行中のクエリに似ています。この概要は、MongoDB内でdb.currentOp（）コマンドを発行するのと似ています。
クラスターの概要-パフォーマンス
MySQL / Galera
パフォーマンスタブは、クラスターの全体的なパフォーマンスと正常性を確認するのにおそらく最適な場所です。 MySQLとGaleraの場合、概要ページ、アドバイザ、ステータス/変数の概要、スキーマアナライザ、トランザクションログで構成されます。
[概要]ページには、クラスター内の最も重要なメトリックの概要がグラフで表示されます。これは明らかに、クラスタータイプごとに異なります。デフォルトでは8つのメトリックが設定されていますが、独自のメトリックを簡単に設定できます。必要に応じて最大20のグラフを設定できます。
アドバイザはClusterControlの重要な機能の1つです。アドバイザは、オンデマンドで実行できるスクリプト化されたチェックです。アドバイザーは、ホストやクラスターについて知られているほとんどすべての事実を評価し、ホストやクラスターの状態について意見を述べることができます。また、問題を解決したり、ホストを改善したりする方法についてアドバイスすることもできます。
最良の部分はまだ来ていません。DeveloperStudioで独自のチェックを作成できます（ ClusterControl-> Manage-> Developer Studio ）、定期的に実行し、[アドバイザ]セクションで再度使用します。この新機能については、今年初めにブログで紹介しました。
MySQLとGaleraのステータス/変数の概要はスキップします。これは参照には役立ちますが、このブログ投稿には役立ちません。ここにあることを知っていれば十分です。
ここで、データベースが成長しているが、過去1週間のデータベースの成長速度を知りたいとします。 ClusterControl内から、データとインデックスの両方のサイズの増加を実際に追跡できます。
また、ディスクの全体的な増加に加えて、上位25の最大のスキーマを報告することもできます。
もう1つの重要な機能は、ClusterControl内のスキーマアナライザーです：
ClusterControlはスキーマを分析し、冗長インデックス、MyISAMテーブル、および主キーのないテーブルを探します。もちろん、一部のアプリケーションがこの方法でテーブルを作成した可能性があるため、主キーなしでテーブルを保持するのは完全にあなた次第ですが、少なくともここで無料でアドバイスを得るのは素晴らしいことです。スキーマアナライザは、問題を修正するために必要なALTERステートメントを推奨します。
PostgreSQL
PostgreSQLの場合、アドバイザ、DBステータス、およびDB変数は次の場所にあります：
MongoDB
MongoDBの場合、MongoStatsとパフォーマンスの概要は[パフォーマンス]タブにあります。 Mongo Statsは、mongostatの出力の概要であり、パフォーマンスの概要は、MongoDBopcountersの優れたグラフィカルな概要を提供します。
最終的な考え
ClusterControlの最も重要な監視およびヘルスチェック機能に注目する方法を紹介しました。 Developer Studioの機能と、独自のチェックを最大限に活用する方法についての別のブログシリーズを間もなく開始するため、これは明らかに旅の始まりにすぎません。また、MongoDBとPostgreSQLのサポートは、MySQLツールセットほど広範囲ではありませんが、継続的に改善していることにも注意してください。
HAProxy、ProxySQL、MaxScaleのパフォーマンス監視とヘルスチェックをスキップした理由を自問するかもしれません。ブログシリーズはこれまでクラスターの展開のみをカバーし、HAコンポーネントの展開はカバーしていなかったため、意図的にこれを行いました。これが次回取り上げるテーマです。