SCUMMダッシュボードを使用したMySQLレプリケーションの効果的な監視：パート2

SCUMMダッシュボードに関する以前のブログでは、MySQLの概要ダッシュボードについて説明しました。 ClusterControlの新しいバージョン（バージョン1.7）は、有用なメトリックの高解像度グラフを多数提供し、各メトリックの意味と、それらがデータベースのトラブルシューティングにどのように役立つかを確認しました。このブログでは、MySQLレプリケーションダッシュボードについて説明します。何を提供する必要があるかについて、このダッシュボードの詳細に進みましょう。

MySQLレプリケーションダッシュボード

MySQLレプリケーションダッシュボードは、MySQLマスターとレプリカの監視を容易にする非常に単純なグラフのセットを提供します。上から順に、レプリカまたはマスターの状態を判断するための最も重要な変数と情報が表示されます。このダッシュボードは、マスターマスターセットアップでスレーブまたはマスターの状態を検査するときに非常に便利な部分を提供します。このダッシュボードでマスターのバイナリログの作成を確認し、特定の期間における生成されたサイズの観点から全体的なディメンションを決定することもできます。

このダッシュボードの最初に、レプリカの正常性に関して必要になる可能性のある最も重要な情報が表示されます。以下のグラフを参照してください：

基本的に、スレーブスレッドのIO_Thread、SQL_Thread、レプリケーションエラー、およびread_only変数が有効になっている場合に表示されます。上記のサンプルスクリーンショットから、すべての情報は、私のスレーブ192.168.70.20が正常で正常に動作していることを示しています。

さらに、Cluster-> Overviewに移動すると、ClusterControlにも収集する情報があります。下にスクロールすると、下のグラフが表示されます：

レプリケーション設定を表示するもう1つの場所は、レプリケーション設定のトポロジビューで、[クラスター]->[トポロジ]からアクセスできます。セットアップ内のさまざまなノード、それらの役割、レプリケーションラグ、取得されたGTIDなどを一目で確認できます。以下のグラフを参照してください：

これに加えて、トポロジビューには、データベースノード、ロードバランサー（ProxySQL / MaxScale / HaProxy）、アービトレーター（garbd）のいずれであっても、データベースクラスターの一部を形成するすべての異なるノード、およびそれらの間の接続も表示されます。ノード、接続、およびそれらのステータスは、ClusterControlによって検出されます。 ClusterControlはノードを継続的に監視し、状態情報を保持しているため、トポロジの変更はすべてWebインターフェイスに反映されます。ノードの障害が報告された場合は、このビューをSCUMMダッシュボードと一緒に使用して、それを引き起こした可能性のある影響を確認できます。

トポロジビューは、ノードの管理、目的のマスターへのオブジェクトのドラッグアンドドロップによるマスターの変更、ノードの再起動、およびデータの同期を行うことができるOrchestratorといくつかの類似点があります。トポロジビューの詳細については、以前のブログ「ClusterControlでのクラスタトポロジの視覚化」をお読みになることをお勧めします。

グラフを進めましょう。

• MySQLレプリケーションの遅延
  このグラフは、MySQLを管理している人、特にマスタースレーブのセットアップで日常的に作業している人には非常によく知られています。このグラフには、このダッシュボードで指定された特定の時間範囲で記録されたすべてのラグの傾向が含まれています。レプリカの定期的な立ち下がり時間を確認したい場合は、このグラフを確認することをお勧めします。 RAIDのBBUが低下して交換が必要な、テーブルに一意のキーがないがマスターにない、不要な全表スキャンまたは全表スキャン、または不正なクエリなど、奇妙な理由でレプリカが遅れる場合があります。開発者によって実行されたままにされました。これは、スレーブラグが重要な問題であるかどうかを判断するための優れた指標でもあります。その場合は、並列レプリケーションを利用することをお勧めします。

• ビンログサイズ
  これらのグラフは相互に関連しています。ビンログサイズのグラフは、ノードがバイナリログを生成する方法を示し、スキャンしている期間に基づいてそのディメンションを決定するのに役立ちます。

• Binlog Data Written Hourly
  Binlog Data Written Hourlyは、当日と前日に記録されたグラフです。これは、書き込みを受け入れているノードの大きさを特定する場合に役立つ可能性があります。これは、後で容量計画に使用できます。

  

• ビンログ数
  特定の週に大量のトラフィックが予想されるとします。マスターとスレーブを通過する書き込みの量を前の週と比較したいとします。このグラフは、この種の状況で非常に役立ちます。生成されたバイナリログがマスター自体で、またはlog_slave_updates変数が有効になっている場合はスレーブでさえ、どれくらいの高さであったかを判断します。このインジケーターを使用して、生成されたマスターとスレーブのバイナリログデータを判別することもできます。特に、log_slave_updatesが有効になっているときに生成されたスレーブでいくつかのテーブルまたはスキーマ（replicate_ignore_db、replicate_ignore_table、replicate_wild_do_table）をフィルタリングしている場合はそうです。

• 1時間ごとに作成されるビンログ
  このグラフは、昨日と今日の日付から1時間ごとに作成されたビンログを比較するための簡単な概要です。

• リレーログスペース
  このグラフは、レプリカから生成されたリレーログの基礎として機能します。 MySQLレプリケーション遅延グラフと一緒に使用すると、生成されるリレーログの数を決定するのに役立ちます。これは、管理者が現在のレプリカのディスク可用性の観点から考慮する必要があります。スレーブが大幅に遅れており、大量のリレーログを生成している場合に問題が発生する可能性があります。これにより、ディスクスペースがすぐに消費される可能性があります。マスターからの書き込み数が多いために、スレーブ/レプリカが大幅に遅れ、大量のログを生成すると、そのレプリカで重大な問題が発生する可能性がある特定の状況があります。これは、運用チームがキャパシティプランニングについて経営陣と話し合うときに役立ちます。

• 1時間ごとに書き込まれるリレーログ
  リレーログスペースと同じですが、昨日と今日の日付から書き込まれたリレーログを比較するための簡単な概要が追加されています。

結論

SCUMMを使用してMySQLレプリケーションを監視すると、運用チームの生産性と効率が向上することを学びました。以前のバージョンの機能をSCUMMで提供されるグラフと組み合わせて使用​​することは、ジムに行って生産性が大幅に向上するのを見るようなものです。これがSCUMMが提供できるものです：ステロイドのモニタリング！ （現在、ジムに行くときにステロイドを服用することを推奨していません！）

このブログのパート3では、InnoDBメトリクスとMySQLパフォーマンススキーマダッシュボードについて説明します。