ClusterControl 1.7.0の最新リリースでは、MySQL用の新しいダッシュボードがいくつか追加されました。 -以前のブログでは、PrometheusとClusterControlを使用してProxySQLを監視する方法を紹介しました。
このブログでは、MySQLの概要ダッシュボードを見ていきます。
そのため、[ダッシュボード]タブでエージェントベースの監視を有効にして、ノードへのメトリックの収集を開始しました。エージェントベースの監視を有効にする場合、「スクレイプ間隔（秒）」を設定するオプションがあることに注意してください。 」と「データ保持（日数） 」。スクレイピング間隔は、Prometheusがターゲットからデータをどれだけ積極的に収集するかを設定する場所であり、データ保持は、データが削除される前にPrometheusによって収集されたデータを保持する期間です。
有効にすると、どのクラスターにエージェントがあり、どのクラスターにエージェントレスモニタリングがあるかを識別できます。
エージェントレスのアプローチと比較して、グラフのデータの粒度はエージェントの方が高くなります。
MySQLグラフ
ClusterControl 1.7.0の最新バージョン（無料でダウンロードできます-ClusterControl Community）には、MySQLサーバーの情報を収集できる次のMySQLダッシュボードがあります。これらは、MySQLの概要、MySQL InnoDBメトリック、MySQLパフォーマンススキーマ、およびMySQLレプリケーションです。
MySQLの概要ダッシュボードで利用可能なグラフについて詳しく説明します。
MySQL概要ダッシュボード
このダッシュボードには、MySQLノードの状態に関する通常の重要な変数または情報が含まれています。このダッシュボードに含まれるグラフは、以下に示すように、ダッシュボードを表示したときに選択されたノードに固有のものです。
26のグラフで構成されていますが、問題を診断するときにこれらすべてが必要なわけではありません。ただし、これらのグラフは、MySQLサーバーの全体的なメトリックの重要な表現を提供します。基本的なものを見ていきましょう。これらはおそらくDBAが日常的に見る最も一般的なものです。
上記の最初の4つのグラフは、MySQLの稼働時間、1秒あたりのクエリ数、およびバッファプール情報とともに、必要になる可能性のある最も基本的なポインタです。上に表示されたグラフから、それらの表現は次のとおりです。
- MySQL接続
ここで、特定の期間にこれまでに割り当てられたクライアント接続の総数を確認します。 - MySQLクライアントスレッドアクティビティ
MySQLサーバーが非常にビジーになる場合があります。たとえば、特定の時間にトラフィックの急増を受け取ることが予想され、実行中のスレッドのアクティビティを監視したい場合があります。このグラフは非常に重要です。たとえば、大規模な更新によって他のスレッドがロックの取得を待機する場合、クエリのパフォーマンスが低下する可能性があります。これにより、実行中のスレッドの数が増加します。キャッシュミス率は、Threads_created/Connectionsとして計算されます。 - MySQLの質問
これらは、特定の期間に実行されているクエリです。スレッドは複数のクエリで構成されるトランザクションである可能性があり、これは確認するのに適したグラフになる可能性があります。 - MySQLスレッドキャッシュ
このグラフは、thread_cache_size値、キャッシュされたスレッド（再利用されたスレッド）、および作成されたスレッド（新しいスレッド）を示しています。このグラフで、多数の着信接続に気付いたときに読み取りクエリを調整する必要があり、作成されたスレッドが急速に増加するなどのインスタンスを確認できます。たとえば、Threads_running / thread_cache_size> 2の場合、thread_cache_sizeを増やすと、サーバーのパフォーマンスが向上する可能性があります。スレッドの作成と破棄にはコストがかかることに注意してください。ただし、MySQLの最近のバージョン（> =5.6.8）では、この変数にはデフォルトで自動サイズ設定があり、変更されていないと見なされる場合があります。
次の4つのグラフは、MySQL一時オブジェクト、MySQL選択タイプ、MySQLソート、およびMySQL低速クエリです。これらのグラフは、長時間実行されるクエリと最適化が必要な大規模なクエリを診断する場合に特に関連しています。
- MySQL一時オブジェクト
このグラフは、一時的なテーブルやファイルがメモリ内に移動する代わりにディスクを使用することになる長時間実行クエリを監視する場合に信頼できる優れたソースになります。これは、特に奇数時にディスクスペースの問題を引き起こす可能性のあるクエリの定期的な発生を探し始めるのに適した場所です。 - MySQLSelectタイプ
パフォーマンスの低下の原因の1つは、完全結合、テーブルスキャン、インデックスを使用していない範囲の選択を使用しているクエリです。このグラフは、クエリがどのように実行されるか、および完全結合から全範囲結合、選択範囲、テーブルスキャンまでのリストの中で最も高い傾向があるものを示します。 - MySQLソート
並べ替えを使用しているクエリと、完了するまでに時間がかかるクエリを診断します。 - MySQLの低速クエリ
遅いクエリの傾向は、このグラフにまとめられています。これは、クエリが遅い頻度を診断する場合に特に役立ちます。調整する必要があるものは何ですか？バッファプールが小さすぎる、インデックスがなく、全表スキャンを実行するテーブル、予期しないスケジュールで実行される論理バックアップなどが考えられます。このグラフと一緒にClusterControlのクエリモニターを使用すると、低速のクエリを特定するのに役立ちます。
次のグラフは、ネットワークアクティビティ、テーブルロック、およびMySQLのアクティビティ中にMySQLが消費している基盤となる内部メモリの詳細です。
- MySQLで中止された接続
中止された接続の数は、このグラフに表示されます。これは、ネットワークが突然閉じられた場所や、インターネット接続がダウンまたは中断された場所など、中止されたクライアントを対象としています。また、クライアントからの接続を確立するときに、中止された接続または間違ったパスワードや不正なパケットなどの試行を記録します。 - MySQLテーブルロック
すぐに付与されたテーブルロックを要求するテーブルと、すぐに取得されていないロックを要求するテーブルの傾向。たとえば、MyISAMテーブルにテーブルレベルのロックがあり、同じテーブルの着信リクエストがある場合、これらをすぐに付与することはできません。 - MySQLネットワークトラフィック
このグラフは、MySQLサーバーでのインバウンドおよびアウトバウンドのネットワークアクティビティの傾向を示しています。 「インバウンド」はMySQLサーバーが受信したデータであり、「アウトバウンド」はサーバーがMySQLサーバーから送信または転送したデータです。このグラフは、特にトラフィックを診断するときにネットワークトラフィックを監視するかどうかを確認するのに最適です。中程度ですが、BLOBデータなどのアウトバウンド転送データが非常に多いのはなぜか疑問に思っています。 - MySQLネットワークの1時間ごとの使用量
受信データと送信データを表示するネットワークトラフィックと同じです。これは「1時間あたり」に基づいており、「最終日」というラベルが付いていることに注意してください。これは、日付ピッカーで選択した期間には従いません。 - MySQL内部メモリの概要
このグラフは、経験豊富なMySQLDBAにはおなじみです。棒グラフのこれらの各凡例は、特にメモリ使用量、バッファプール使用量、または適応ハッシュインデックスサイズを監視する場合に非常に重要です。
次のグラフは、統計のチェックなど、DBAが信頼できるカウンターを示しています。たとえば、選択、挿入、更新の統計、実行されたマスターステータスの数、実行されたSHOW VARIABLESの数、チェックテーブルスキャンを実行する不正なクエリや、read_*カウンターなどを調べてインデックスを使用しないテーブルがある場合。
- トップコマンドカウンター（毎時）
これらは、挿入、削除、更新、プロセスリストの収集、スレーブステータス、ステータスの表示（MySQLサーバーのヘルス統計）などの実行されたコマンドの統計を確認するたびに確認する必要があるグラフです。 ）、 などなど。これは、どの種類のMySQLコマンドカウンターが最上位であるかを確認したい場合や、パフォーマンスの調整やクエリの最適化が必要な場合に適しています。また、必要のないときに積極的に実行されているコマンドを特定できる場合もあります。 - MySQLハンドラー
多くの場合、DBAはこれらのハンドラーを調べて、MySQLサーバーでクエリがどのように実行されているかを確認します。基本的に、このグラフはMySQLのハンドラーAPIからのカウンターをカバーしています。 MySQLのストレージAPIのDBAの最も一般的なハンドラーカウンターは、Handler_read_first、Handler_read_key、Handler_read_last、Handler_read_next、Handler_read_prev、Handler_read_rnd、およびHandler_read_rnd_nextです。チェックするMySQLハンドラーはたくさんあります。こちらのドキュメントでそれらについて読むことができます。 - MySQLトランザクションハンドラー
MySQLサーバーがXAトランザクション、SAVEPOINT、ROLLBACKTOSAVEPOINTステートメントを使用している場合。次に、このグラフは参照するのに適しています。このグラフを使用して、サーバーのすべての内部コミットを監視することもできます。 Handler_commitのカウンターは、SELECTステートメントでも増分しますが、COMMITステートメントの呼び出し中にバイナリログに移動する挿入/更新/削除ステートメントとは異なることに注意してください。
次のグラフは、プロセスの状態とその1時間ごとの使用量に関する傾向を示しています。棒グラフの凡例には、DBAがチェックする重要なポイントがたくさんあります。ディスクスペースの問題、接続の問題に遭遇し、接続プールが期待どおりに機能しているかどうか、高いディスクI / O、ネットワークの問題などを確認します。
- プロセス状態/1時間ごとの上位プロセス状態
このグラフでは、プロセスリストで実行されているクエリの上位スレッドの状態を監視できます。これは、解決が必要な未解決のステータスをここで調べることができるようなDBAタスクにとって非常に有益で役立ちます。たとえば、テーブルを開く 状態は非常に高く、その最小値はほぼ最大値に近いです。これは、table_open_cacheを調整する必要があることを示している可能性があります。 統計の場合 が高く、サーバーの速度が低下していることに気付いた場合は、サーバーがディスクにバインドされていることを示している可能性があり、バッファプールの増加を検討する必要がある場合があります。 tmpテーブルの作成が多数ある場合 次に、遅いログを確認し、問題のあるクエリを最適化する必要がある場合があります。 MySQLスレッドの状態の完全なリストについては、ここでマニュアルを確認できます。
次に確認するグラフは、クエリキャッシュ、MySQLテーブル定義キャッシュ、MySQLがシステムファイルを開く頻度についてです。
- MySQLクエリキャッシュのメモリ/アクティビティ
これらのグラフは相互に関連しています。 query_cache_size<>0およびquery_cache_type<>0がある場合は、このグラフが役立ちます。ただし、MySQLの新しいバージョンでは、MySQLクエリキャッシュがパフォーマンスの問題を引き起こすことがわかっているため、クエリキャッシュは非推奨としてマークされています。将来的にはこれは必要ないかもしれません。 MySQL 8.0の最新バージョンでは、大幅な改善が行われています。メモリバッファ内のキャッシュ情報を処理するためのいくつかの戦略が付属しているため、パフォーマンスが向上する傾向があります。 - MySQLファイルの開口部
このグラフは、MySQLサーバーの稼働時間以降に開かれたファイルの傾向を示していますが、ソケットやパイプなどのファイルは除外されています。また、Innodb_num_open_filesである独自のカウンターがあるため、ストレージエンジンによって開かれるファイルも含まれません。 - MySQLOpenファイル
このグラフは、現在開いているInnoDBファイル、現在開いているMySQLファイル、およびopen_files_limit変数を確認する場所です。 - MySQLテーブルのオープンキャッシュステータス
ここで非常に低いtable_open_cacheを設定している場合、このグラフは、キャッシュに失敗したテーブル（新しく開いたテーブル）またはオーバーフローが原因で失敗したテーブルについて示します。プロセスリストで「テーブルを開いています」ステータスの数が多いか多すぎる場合、このグラフはこれを判断するための参照として役立ちます。これにより、table_open_cache変数を増やす必要があるかどうかがわかります。 - MySQLオープンテーブル
MySQLテーブルのオープンキャッシュステータスに関連して、このグラフは、テーブルのオープンテーブルまたはOpen_tablesステータス変数の大幅な増加に気付いた場合に、table_open_cacheを増やす必要があるか、または下げる必要があるかを特定したい場合に役立ちます。 。 table_open_cacheは大量のメモリスペースを使用する可能性があるため、特に実稼働システムでは注意して設定する必要があることに注意してください。 - MySQLテーブル定義キャッシュ
Open_table_definitionsおよびOpened_table_definitionsステータス変数の数を確認する場合は、このグラフが必要です。 MySQLの新しいバージョン（> =5.6.8）の場合、自動サイズ変更機能があるため、この変数の値を変更してデフォルト値を使用する必要がない場合があります。
結論
ClusterControl 1.7.0の最新バージョンでのSCUMMの追加は、多くの主要なDBAタスクに重要な新しい利点を提供します。新しいグラフは、DBAまたはシステム管理者が通常対処しなければならない問題の原因を簡単に特定し、適切な解決策をより迅速に見つけるのに役立ちます。
ClusterControl 1.7.0をSCUMM（無料でダウンロードできます-ClusterControlコミュニティ）で使用する際の経験と考えをお聞かせください。
このブログのパート2では、SCUMMダッシュボードを使用したMySQLレプリケーションの効果的な監視について説明します。