アクティビティのトレースと追跡

  • 11 分

データベースの保守の大部分は、パフォーマンス チューニングです。 オンプレミスのデータベースで確認するために使用していたのと同じログ ファイルを、Azure Database for MySQL/PostgreSQL でも使用できます。

データベースを Azure に移行したら、ログ ファイルの確認を続けて、データベースのパフォーマンスが維持されていることを確認する必要があります。

このユニットでは、Azure で PostgreSQL と MySQL のログ ファイルが格納されている場所と、それに含まれている詳細のレベルを確認します。

サーバー ログを使用してデータベースのアクティビティを追跡する

Azure Database for MySQL/PostgreSQL では、サーバー ログに診断情報も記録されます。 サーバー ログは、MySQL および PostgreSQL のネイティブなメッセージ ログ ファイルです (Azure Database for MySQL/PostgreSQL ではアクセスできないトランザクション ログ ファイルではありません)。 これらのファイルには、データベースの問題をデバッグするために使用するメッセージ、サーバーの状態、その他のエラー情報が含まれています。 サーバー ログは、最大 7 日間保持されます (サーバー ログ ファイルの合計サイズが 7 GB を超える場合は、それより短い期間)。

Azure Database for MySQL と Azure Database for PostgreSQL により、サーバー ログにさまざまな詳細情報が記録されます。 以降のセクションでは、各サービスのサーバー ログを個別に説明します。

Azure Database for MySQL のサーバー ログ

Azure Database for MySQL では、MySQL サーバーの "低速クエリ ログ" と "監査ログ" で通常使用できる情報がサーバー ログで提供されます。

低速クエリ ログの情報を使用すると、実行が低速なクエリを識別できます。 既定で、低速クエリ ログは無効です。 これを有効にするには、slow_query_log サーバー パラメーターを ON に設定します。 低速クエリ ログを構成して、"低速クエリ" で意図されている内容を決定するには、次のサーバー パラメーターを使用します。

  • log_queries_not_using_indexes。 このパラメーターは、ON または OFF です。 インデックス検索ではなくフル テーブル スキャンが実行される可能性があるすべてのクエリを記録するには、ON に設定します。
  • log_throttle_queries_not_using_indexes。 1 分あたりにログに記録できる、インデックスを使用しない低速クエリの最大数を指定します。
  • log_slow_admin_queries。 実行の遅い管理クエリをログに含めるには、このパラメーターを ON に設定します。
  • long_query_time。 "実行が遅い" と見なされるクエリのしきい値 (秒)。

低速クエリ ログと監査ログを有効にすると、サーバーの [サーバー ログ] ページにログ ファイルが表示されるようになります。 新しい低速クエリ ログが毎日作成されます。 ダウンロードするには、ログ ファイルをクリックします。

Image of the Server logs page for Azure Database for MySQL.

監査ログを有効にするには、audit_log_enabled サーバー パラメーターを ON に設定します。 監査ログは、次のパラメーターを使用して構成します。

  • audit_log_events。 監査するイベントを指定します。 Azure portal では、このパラメーターには、[CONNECTION]、[DDL]、[DML]、[ADMIN] などのイベントのドロップダウン リストが用意されています。
  • audit_log_exclude_users。 このパラメーターは、監査ログにアクティビティを含めないユーザーのコンマ区切りのリストです。

低速クエリ ログと監査ログを 7 日間を超えて保持する必要がある場合は、Azure Storage に転送するように設定します。 サーバーの [診断の設定] ページを使用して、[診断設定の追加] を選択します。 [診断の設定] ページで、[ストレージ アカウントにアーカイブ] を選択し、ログ ファイルを保存するストレージ アカウントを選択して (このストレージ アカウントは既に存在している必要があります)、[MySqlSlowLogs] と [MySqlAuditLogs] を選択し、保有期間を最大 365 日に指定します。 この期間内は、Azure Storage からログ ファイルをいつでもダウンロードできます。 [保存] を選択します。

Image of the Diagnostic settings page for Azure Database for MySQL.

低速クエリ ログのデータは、insights-logs-mysqlslowlogs という名前のコンテナー内の BLOB に JSON 形式で書き込まれます。 ログ ファイルが Azure Storage に表示されるまでに最大 10 分かかることがあります。 監査レコードは、同様に JSON 形式で insights-logs-mysqlslowlogs BLOB コンテナーに格納されます。

Azure Database for PostgreSQL のサーバー ログ

Azure Database for PostgreSQL のサーバー ログには、エラー ログ ファイルとクエリ ログ ファイルが含まれています。 これらのファイルの情報を使用すると、エラーや非効率的なクエリの原因を特定できます。

ログ記録を有効にするには、さまざまな log_ サーバー構成パラメーターを ON に設定します。 これらのパラメーターには、以下のものがあります。

  • log_checkpoints。 チェックポイントは、すべてのデータ ファイルがトランザクション ログの最新情報で更新されたときに発生します。 サーバーで障害が発生した場合、このポイントは、トランザクション ログからロール フォワードすることによって復旧を開始する必要がある時間を示します。
  • log_connection と log_disconnections。 これらの設定では、成功した各接続と各セッションの終了が記録されます。
  • log_duration。 この設定では、完了した各 SQL ステートメントの実行時間が記録されます。
  • log_lock_waits。 この設定では、ロック待機イベントが記録されます。 ロック待機は、アプリケーション コードでのトランザクションの実装に問題があることが原因である可能性があります。
  • log_statement_stats。 この設定では、サーバーのパフォーマンスに関する累積情報がログに書き込まれます。

Azure Database for PostgreSQL には、記録される情報を微調整するためのパラメーターも用意されています。

  • log_error_verbosity。 この設定では、ログに記録される各メッセージの記録される詳細のレベルを指定します。
  • log_retention_days。 これは、各ログ ファイルが削除されるまでにサーバーで保持される日数です。 既定値は 3 日間で、最大 7 日間に設定できます。
  • log_min_messages と log_min_error_statement。 ステートメントを記録する警告とエラーのレベルを指定するには、これらのパラメーターを使用します。

Azure Database for MySQL と同様に、Azure Database for PostgreSQL によって生成されるログ ファイルは、[サーバー ログ] ページで使用できます。 [診断の設定] ページを使用して、Azure Storage にログをコピーすることもできます。

クエリ パフォーマンスを追跡する

クエリ ストアは Azure によって提供される追加機能であり、実行状況に問題があるクエリの特定と追跡に役立ちます。 これは、Azure Database for MySQL と Azure Database for PostgreSQL で使用します。

クエリ パフォーマンスの追跡を有効にする

クエリ ストアでは、Azure Database for MySQL の mysql スキーマ、および Azure Database for PostgreSQL の azure_sys という名前のデータベースに情報が記録されます。 クエリ ストアでは、クエリの実行に関するデータと待機統計に関する情報という 2 種類の情報をキャプチャできます。 クエリ ストアは既定では無効になっています。 有効にするには、次の手順を実行します。

  • Azure Database for MySQL を使用している場合は、サーバー パラメーター query_store_capture_mode と query_store_wait_sampling_capture_mode を ALL に設定します。
  • Azure Database for PostgreSQL を使用している場合は、サーバー パラメーター pg_qs.query_capture_mode を ALL または TOP に設定し、pgms_wait_sampling.query_capture_mode パラメーターを ALL に設定します。

クエリ パフォーマンスのデータを分析する

クエリ ストアによって使用されるテーブルに対して、直接クエリを実行できます。 Azure Database for MySQL を実行している場合は、サーバーに接続して次のクエリを実行します。

SELECT * FROM mysql.query_store;

SELECT * FROM mysql.query_store_wait_stats;

Azure Database for PostgreSQL を使用している場合は、代わりに次のクエリを実行します。

SELECT * FROM query_store.qs_view;

SELECT * FROM query_store.pgms_wait_sampling_view;

どちらの場合も、最初のクエリでは、最近実行した各クエリのテキストと、クエリのコンパイルと実行に要した時間に関する多数の統計が表示されます。 2 番目のクエリでは、待機イベントに関する情報が表示されます。 待機イベントは、別のクエリによって保持されているリソースを必要とするために、あるクエリを実行できない場合に発生します。

クエリ ストアを直接調べる場合は、独自のカスタム レポートを生成して、システムの動作状況に関する詳細な分析情報を得ることができます。 ただし、使用可能なデータの量によっては、何が起こっているかを理解することが難しい場合があります。 Azure Database for MySQL/PostgreSQL には、このデータのナビゲートに役立つ 2 つの追加ツール (Query Performance Insight とクエリに関する推奨事項) が用意されています。

Query Performance Insight は、サーバーの [Query Performance Insight] ページから使用できるグラフィカル ユーティリティです。 [実行時間の長いクエリ] タブには、最も実行時間の長いクエリの統計情報が表示されます。 [期間] を指定して、数分の範囲を拡大表示します。 凡例には、各クエリのテキストが、クエリが実行された期間と回数と共に表示されます。 グラフでは、各クエリの実行時間の比較ビューが提供されます。 各クエリの平均時間によってデータが表示されますが、各クエリの合計時間 ("実行時間" * "実行回数") を表示することも有益です。 下の画像は例を示しています。

Image of the Query Performance Insight page for Azure Database for PostgreSQL, showing the Long running queries tab.

[待機の統計] タブには、各クエリの待機イベント情報が表示されます。 さまざまなリソースを待機しているクエリによって費やされた時間が表示されます。

Image of the Query Performance Insight page for Azure Database for PostgreSQL, showing the Wait statistics tab.

待機イベントは、通常、次の 3 つのカテゴリに分類されます。

  • ロックの待機。 これらのイベントは、別のクエリによってロックされているデータの読み取りまたは変更をクエリで試みている場合に発生します。 多数のロック待機が発生した場合は、実行時間の長いトランザクションを確認するか、制限の厳しい分離レベルが使用されている操作を確認してください。
  • I/O の待機。 この種類の待機は、クエリで大量の入出力が実行されている場合に発生します。 これは、クエリのデザインが適切でない (WHERE 句を確認します) こと、非効率的な結合操作、またはインデックスがないためにフル テーブル スキャンが実行されたことが原因である可能性があります。
  • メモリの待機。 メモリの待機は、クエリの処理に使用できるメモリが不足している場合に発生します。 クエリで大量のデータを読み取ろうとしているか、メモリを占有している他のクエリによってブロックされている可能性があります。 ここでも、インデックスがないために、クエリによってテーブル全体がメモリに読み込まれていることを示している可能性があります。

1 つの形式の待機によって別の待機が引き起こされる可能性も高いため、これらの問題を分離して調査することができない場合があります。 たとえば、様々なテーブルのデータの読み取りおよび更新を行うトランザクションは、メモリ待機の影響を受ける可能性があります。 逆に、このトランザクションでデータがロックされているために、別のトランザクションでロック待機が発生する可能性があります。

サーバーの [パフォーマンスの推奨事項] ページでは、クエリ ストアに保持されている情報を取得し、それを使用して、発生しているワークロードに合わせてデータベースをチューニングするための推奨事項が提示されます。