sql >> データベース >  >> RDS >> Mysql

MySQL8.0で監視するもの

    すべての環境で監視は必須であり、データベースも例外ではありません。データベースインフラストラクチャを稼働させたら、何が起こっているかを把握する必要があります。すべてが正常に機能していることを確認したい場合だけでなく、システムの成長と進化の間に必要な調整を行った場合にも、監視は必須です。これにより、傾向を特定したり、アップグレードや改善を計画したり、新しいバージョンやさまざまな目的などで発生する可能性のある問題やエラーに適切に対応したりできます。

    データベーステクノロジーごとに、監視するものが異なります。これらの一部は、データベースエンジン、ベンダー、または使用している特定のバージョンに固有のものです。データベースクラスターは基盤となるインフラストラクチャに大きく依存しているため、データベース管理者もネットワークと運用の統計情報を確認できます。

    複数のデータベースシステムを実行している場合、これらのシステムの監視は非常に面倒になる可能性があります。

    このブログでは、MySQL8.0環境を監視するために必要なものを見ていきます。また、データベースの状態を無料で追跡するのに役立つ可能性のあるクラスター制御監視機能についても説明します。

    OSとデータベースシステムの監視

    データベースクラスターまたはノードを監視する場合、考慮すべき2つの主要なポイントがあります。オペレーティングシステムとMySQLインスタンス自体です。両側から監視するメトリックと、それを実行する方法を定義する必要があります。システムの意味で常にパラメータに従う必要があり、動作モデルの変更を探す必要があります。

    パラメータの1つが影響を受けると、他のパラメータにも影響を与える可能性があるため、問題のトラブルシューティングがより複雑になることに注意してください。このタスクを可能な限り単純にするためには、適切な監視およびアラートシステムを用意することが不可欠です。

    必要なすべての指標を網羅するツールを見つけるのは難しいため、ほとんどの場合、いくつかのツールを使用する必要があります。

    OSシステムの監視

    1つの主要なこと(すべてのデータベースエンジン、さらにはすべてのシステムに共通)は、オペレーティングシステムの動作を監視することです。ここで確認すべき点がいくつかあります。以下に、データベースサーバーで監視する上位のシステムリソースを示します。実際には、最初に確認することのリストでもあります。

    CPU使用率

    制限に達しない限り、CPU使用率が高いことは悪いことではありません。通常の動作でない場合は、CPU使用率の割合が高すぎると問題になる可能性があります。この場合、この問題を引き起こしている1つまたは複数のプロセスを特定することが不可欠です。問題がデータベースプロセスにある場合は、データベース内で何が起こっているかを確認する必要があります。

    RAMメモリまたはSWAPの使用量

    理想的には、データベース全体をメモリに保存する必要がありますが、これが常に可能であるとは限りません。 MySQLにできる限り多くを与えますが、他のプロセスが機能するのに十分な量を残します。

    このメトリックに高い値が表示され、システムで何も変更されていない場合は、データベース構成を確認する必要があります。 shared_buffersやwork_memなどのパラメーターは、MySQLデータベースに使用できるメモリの量を定義するため、これに直接影響を与える可能性があります。スワップは緊急用であり、使用しないでください。オペレーティングシステムがMySQLにスワップの使用を決定させるように設定されていることを確認してください。

    ディスク使用量

    ディスク使用量は、監視および警告するための主要なメトリックの1つです。新しいデータ、一時ファイル、スナップショット、またはバックアップ用の空き容量が常にあることを確認してください。

    ハードメトリック値を監視するだけでは不十分です。 MySQLログファイルに多数のエラーが記録されたり、キャッシュ構成がお粗末なため、ディスクスペースの使用量が異常に増加したり、ディスクアクセスが過剰に消費されたりすると、重要なディスクアクセス消費が発生する可能性があります。メモリを使用してクエリを処理します。警告や重要な指標にまだ達していない場合でも、異常な行動を捕らえることができることを確認してください。

    スペースの監視に加えて、ディスクアクティビティも監視する必要があります。監視する上位の値は次のとおりです。

      読み取り/書き込みリクエスト
    • IOキューの長さ
    • 平均IO待機 平均読み取り/書き込み時間 読み取り/書き込み帯域幅

    Perconaのiostatまたはpt-diskstatsを使用して、これらすべての詳細を確認できます。

    ディスクのパフォーマンスに影響を与える可能性のあるものは、多くの場合、ディスクとの間のデータ転送に関連しているため、他のユーザーから開始できるよりも異常なプロセスを監視します。

    平均負荷 オールインワンのパフォーマンスメトリック。 Linux Loadを理解することは、OSとデータベースに依存するシステムを監視するための鍵です。

    上記の3つのポイントに関連する負荷平均。 CPU、RAM、またはディスクの過剰な使用により、高い負荷平均が生成される可能性があります。

    ネットワーク

    バックアップを実行したり、大量のデータを転送したりしない限り、ボトルネックになることはありません。

    アプリケーションがデータベースに接続できない(または失われたパッケージを接続できない)ため、ネットワークの問題がすべてのシステムに影響を与える可能性があるため、これは実際に監視する重要な指標です。遅延やパケット損失を監視できます。主な問題は、ネットワークの飽和、ハードウェアの問題、または単にお粗末なネットワーク構成である可能性があります。

    データベースの監視

    監視は必須ですが、通常は無料ではありません。監視する量によっては、データベースのパフォーマンスに常にコストがかかるため、使用しないものの監視は避ける必要があります。

    一般に、データベースを監視するには、ログから、またはデータベース側からクエリを実行する2つの方法があります。

    ログの場合、ログを使用できるようにするには、高いログレベルが必要です。これにより、高いディスクアクセスが生成され、データベースのパフォーマンスに影響を与える可能性があります。

    クエリモードの場合、データベースへの各接続はリソースを使用するため、データベースのアクティビティと割り当てられたリソースによっては、パフォーマンスにも影響する可能性があります。

    もちろん、MySQLには多くのメトリックがあります。ここでは、最も重要なものに焦点を当てます。

    アクティブセッションの監視

    アクティブなセッションの数とDBのアップダウンステータスも追跡する必要があります。多くの場合、問題を理解するには、データベースの実行時間を確認する必要があります。これを使用してリスポーンを検出できます。

    次は、セッションの数です。制限に近づいている場合は、何かが間違っているかどうか、またはmax_connections値をインクリメントする必要があるかどうかを確認する必要があります。数の違いは、接続の増加または減少である可能性があります。接続プール、ロック、またはネットワークの問題の不適切な使用は、接続数に関連する最も一般的な問題です。

    ここでの重要な値は

      稼働時間
    • Threads_connected
    • Max_used_connections
    • Aborted_connects
    データベースロック

    別のクエリを待機しているクエリがある場合は、その別のクエリが通常のプロセスであるか、何か新しいものであるかを確認する必要があります。たとえば、誰かが大きなテーブルを更新している場合、このアクションはデータベースの通常の動作に影響を及ぼし、多数のロックを生成する可能性があります。

    レプリケーションの監視

    レプリケーションを監視するための主要なメトリックは、ラグとレプリケーションの状態です。アップダウンステータスだけでなく、この値の継続的な増加は、スレーブがマスターに追いつくことができないことを意味するため、あまり良い兆候ではないため、ラグもあります。

    最も一般的な問題は、ネットワークの問題、ハードウェアリソースの問題、または寸法の問題です。レプリケーションの問題に直面している場合は、高可用性環境を確保するために修正する必要があるため、このことをできるだけ早く知る必要があります。

    レプリケーションは、スレーブステータスと次のパラメータを確認することで最適に監視されます。

    • SLAVE_RUNNING
    • SLAVE_IO_Running
    • SLAVE_SQL_RUNNING
    • LAST_SQL_ERRNO
    • SECONDS_BEHIND_MASTER
    バックアップ

    残念ながら、バニラコミュニティエディションにはバックアップマネージャーが付属していません。バックアップが完了したかどうか、およびバックアップが使用可能かどうかを知っておく必要があります。通常、この最後の点は考慮されませんが、バックアッププロセスでおそらく最も重要なチェックです。ここでは、percona-xtrabackupやClusterControlなどの外部ツールを使用する必要があります。

    データベースログ

    FATALやデッドロックなどのエラー、または認証の問題や長時間実行されるクエリなどの一般的なエラーについても、データベースログを監視する必要があります。ほとんどのエラーはログファイルに書き込まれ、修正に役立つ詳細な情報が含まれています。注意が必要な一般的な障害点は、エラー、ログファイルのサイズです。エラーログの場所は、log_error変数の下にあります。

    外部ツール

    最後になりましたが、データベースアクティビティを監視するための便利なツールのリストを見つけることができます。

    PerconaToolkit-MySQLおよびOSのアクティビティを分析するためのPerconaのLinuxツールのセットです。ここで見つけることができます。 Debian、Ubuntu、Redhatなどの最も人気のある64ビットLinuxディストリビューションをサポートしています。

    mysqladmin-mysqladminは、MySQLデーモンの管理プログラムです。サーバーの状態(ping)の確認、プロセスの一覧表示、変数の値の確認に使用できますが、データベースの作成/削除、ログ、統計、テーブルのフラッシュ(リセット)、実行中のクエリの強制終了などの管理作業も実行できます。サーバーを停止し、レプリケーションを制御します。

    innotop-SHOWステートメントの拡張ビューを提供します。これは非常に強力で、調査時間を大幅に短縮できます。バニラMySQLサポートの中で、Galeraビューとマスタースレーブレプリケーションの詳細を確認できます。

    mtop-MySQLサーバーを監視して、完了するのに最も時間がかかるクエリを表示します。機能には、完全なクエリを表示するためのプロセスの「ズームイン」、クエリのクエリオプティマイザ情報の「説明」、およびクエリの「強制終了」が含まれます。さらに、サーバーのパフォーマンス統計、構成情報、およびチューニングのヒントが提供されます。

    Mytop-ターミナルで実行され、Linuxとよく似た、スレッド、クエリ、低速クエリ、稼働時間、読み込みなどに関する統計を表形式で表示します

    結論

    このブログは、データベースモニタリングを強化する方法を網羅的にガイドすることを目的としたものではありませんが、重要になる可能性のあるものと、監視できる基本的なパラメータのいくつかをより明確に示してくれることを願っています。以下のコメントで重要なものを見逃した場合は、遠慮なくお知らせください。


    1. OracleのCONNECTBY... START WITHと同等のPostgreSQL構文は何ですか?

    2. Rails / Postgresql SQLの違い(日付付き)

    3. PostgreSQLはデータベースをどこに保存しますか?

    4. catcon.plを使用してマルチテナント環境でSQLスクリプトを実行する