Amazon Aurora グローバルデータベースのモニタリング - Amazon Aurora

Amazon Aurora グローバルデータベースのモニタリング

Aurora グローバルデータベースを構成している Aurora DB クラスターを作成するときは、DB クラスターのパフォーマンスを監視できる多くのオプションを選択できます。オプションは以下のとおりです。

  • Amazon RDSPerformance Insights –基盤となる Aurora データベースエンジンでパフォーマンススキーマを有効にします。Performance Insights と Aurora グローバルデータベースの詳細については、「Amazon RDS Performance Insights を使用した Amazon Aurora グローバルデータベースのモニタリング」を参照してください。

  • 拡張モニタリング–CPU のプロセスまたはスレッド使用率のメトリクスを生成します。

  • Amazon CloudWatch Logs– 指定されたログタイプを CloudWatch Logs にパブリッシュします。エラーログはデフォルトでパブリッシュされますが、Aurora データベースエンジンに固有の、その他のログを選択することが可能です。

    • Aurora MySQL– ベースの Aurora DB クラスターの場合、監査ログ、全般ログ、スロークエリログをエクスポートすることができます。

    • Aurora PostgreSQL– ベースの Aurora DB クラスターの場合、PostgreSQL ログをエクスポートすることができます。

  • Aurora PostgreSQL– ベースのグローバルデータベースの場合、特定の関数を使用して、Aurora グローバルデータベースとそのインスタンスのステータスをチェックすることができます。この方法については、「Aurora PostgreSQL ベースの Aurora グローバルデータベースのモニタリング」を参照してください。

次のスクリーンショットは、Aurora グローバルデータベースの、プライマリ Aurora DB クラスターの [モニタリング] タブで使用できるオプションの一部です。


        Auroraグローバルデータベースに含まれる、選択した Aurora DB クラスターの [モニタリング] ページのスクリーンショット

詳細については、「Amazon Aurora DB クラスターのモニタリング」を参照してください。

Amazon RDS Performance Insights を使用した Amazon Aurora グローバルデータベースのモニタリング

Amazon RDS Performance Insights は Aurora グローバルデータベースで使用できます。この機能は、Aurora グローバルデータベースの各 Aurora DB クラスターで個別に有効にします。有効にするには、[データベースの作成] ページの [追加設定] のセクションで、[Performance Insights を有効にする] を選択します。あるいは、起動後の実行中に、この機能を使用するように Aurora DB クラスターを変更することもできます。Aurora グローバルデータベースに含まれる各クラスターで、Performance Insights を有効または無効にすることができます。

Performance Insights が作成したレポートは、グローバルデータベースの各クラスターに適用されます。すでに Performance Insights を使用している Aurora グローバルデータベースに新しいセカンダリ AWS リージョンを追加するときは、必ず、新たに追加したクラスターで Performance Insights を有効にします。既存のグローバルデータベースから Performance Insights 設定が継承されることはありません。

グローバルデータベースにアタッチされている DB インスタンスの Performance Insights ページを表示したまま、AWS リージョンを切り替えることができます。ただし、AWS リージョンを切り替えた直後は、パフォーマンス情報が表示されない場合があります。DB インスタンスの名前が AWS の各リージョンで同じになることがありますが、関連付けられた Performance Insights の URL は、各 DB インスタンスで異なります。AWS リージョンを切り替えたら、Performance Insights のナビゲーションペインで DB インスタンスの名前を再度選択します。

グローバルデータベースに関連付けられた DB インスタンスでは、パフォーマンスに影響を与える要因が AWS の各リージョンで異なる場合があります。例えば、DB インスタンスのキャパシティーは、各 AWS リージョンで異なります。

Performance Insights の詳細については、「Amazon Aurora での Performance Insights の使用」を参照してください 。

Aurora PostgreSQL ベースの Aurora グローバルデータベースのモニタリング

グローバルデータベースのステータスを表示するには、aurora_global_db_status 関数 と aurora_global_db_instance_status 関数を使用します。

注記

Aurora PostgreSQL のみが、aurora_global_db_status 関数および aurora_global_db_instance_status 関数をサポートします。

Aurora PostgreSQL ベースのグローバルデータベースをモニタリングするには

  1. psql などの PostgreSQL ユーティリティを使用して、グローバルデータベースのプライマリクラスターエンドポイントに接続します。接続方法の詳細については、「Amazon Aurora グローバルデータベースへの接続」を参照してください。

  2. psql コマンドで aurora_global_db_status 関数を使用して、プライマリボリュームとセカンダリボリュームを一覧表示します。これは、グローバルデータベースのセカンダリ DB クラスターの遅延時間を示します。

    postgres=> select * from aurora_global_db_status();
    aws_region | highest_lsn_written | durability_lag_in_msec | rpo_lag_in_msec | last_lag_calculation_time | feedback_epoch | feedback_xmin ------------+---------------------+------------------------+-----------------+----------------------------+----------------+--------------- us-east-1 | 93763984222 | -1 | -1 | 1970-01-01 00:00:00+00 | 0 | 0 us-west-2 | 93763984222 | 900 | 1090 | 2020-05-12 22:49:14.328+00 | 2 | 3315479243 (2 rows)

    出力には、次の列を含むグローバルデータベースの各 DB クラスターの行が含まれます。

    • aws_region – この DB クラスターがある AWS リージョン。AWS リージョンをエンジン別にリスト化した表については、「リージョンとアベイラビリティーゾーン」を参照してください。

    • highest_lsn_written – この DB クラスターに現在書き込まれているログシーケンス番号 (LSN) の最大値。

      ログシーケンス番号 (LSN) は、データベーストランザクションログ内のレコードを識別する一意の連続番号です。LSN は、より大きな LSN が後のトランザクションを表すように順序付けられます。

    • durability_lag_in_msec – セカンダリ DB クラスター (highest_lsn_written) に書き込まれた最大ログシーケンス番号とプライマリ DB クラスターに書き込まれた highest_lsn_written とのタイムスタンプ差。

    • rpo_lag_in_msec – リカバリポイント目標 (RPO) の遅れ。この遅延は、セカンダリ DB クラスターに保存された最新のユーザートランザクションコミットと、プライマリ DB クラスターに保存された最新のユーザートランザクションコミットの間の時間差です。

    • last_lag_calculation_timereplication_lag_in_msec および rpo_lag_in_msec に対して値が最後に計算されたタイムスタンプ。

    • feedback_epoch – セカンダリ DB クラスターがホットスタンバイ情報を生成するときに使用するエポック。

      ホットスタンバイとは、サーバーが復旧モードまたはスタンバイモードのときに DB クラスターが接続してクエリを実行できる場合です。ホットスタンバイのフィードバックは、ホットスタンバイの場合の DB クラスターに関する情報です。詳細については、PostgreSQL ドキュメントの「ホットスタンバイ」を参照してください。

    • feedback_xmin – セカンダリ DB クラスターで使用される最小 (最も古い) のアクティブなトランザクション ID。

  3. aurora_global_db_instance_status 関数を使用して、プライマリ DB クラスターとセカンダリ DB クラスターの両方のセカンダリ DB インスタンスをすべて一覧表示します。

    postgres=> select * from aurora_global_db_instance_status();
    server_id | session_id | aws_region | durable_lsn | highest_lsn_rcvd | feedback_epoch | feedback_xmin | oldest_read_view_lsn | visibility_lag_in_msec --------------------------------------------+--------------------------------------+------------+-------------+------------------+----------------+---------------+----------------------+------------------------ apg-global-db-rpo-mammothrw-elephantro-1-n1 | MASTER_SESSION_ID | us-east-1 | 93763985102 | | | | | apg-global-db-rpo-mammothrw-elephantro-1-n2 | f38430cf-6576-479a-b296-dc06b1b1964a | us-east-1 | 93763985099 | 93763985102 | 2 | 3315479243 | 93763985095 | 10 apg-global-db-rpo-elephantro-mammothrw-n1 | 0d9f1d98-04ad-4aa4-8fdd-e08674cbbbfe | us-west-2 | 93763985095 | 93763985099 | 2 | 3315479243 | 93763985089 | 1017 (3 rows)

    出力には、次の列を含むグローバルデータベースの各 DB インスタンスの行が含まれます。

    • server_id – DB インスタンスのサーバー識別子。

    • session_id – 現在のセッションの一意の識別子。

    • aws_region – この DB インスタンスがある AWS リージョン。AWS リージョンをエンジン別にリスト化した表については、「リージョンとアベイラビリティーゾーン」を参照してください。

    • durable_lsn – ストレージで耐久性のある LSN。

    • highest_lsn_rcvd – 書き込み DB インスタンスから DB インスタンスが受信した最高の LSN。

    • feedback_epoch – DB インスタンスがホットスタンバイ情報を生成するときに使用するエポック。

      ホットスタンバイとは、サーバーが復旧モードまたはスタンバイモードのときに DB インスタンスが接続してクエリを実行できる場合です。ホットスタンバイのフィードバックは、ホットスタンバイの場合の DB インスタンスに関する情報です。詳細については、ホットスタンバイに関する PostgreSQL ドキュメントを参照してください。

    • feedback_xmin – DB インスタンスで使用される最小 (最も古い) のアクティブなトランザクション ID。

    • oldest_read_view_lsn – ストレージから読み取るために DB インスタンスが使用する最も古い LSN。

    • visibility_lag_in_msec – この DB インスタンスが書き込み DB インスタンスからどのくらい遅れているか。

これらの値が時間の経過とともにどのように変化するかを確認するには、テーブルの挿入に 1 時間かかる次のトランザクションブロックを検討してください。

psql> BEGIN; psql> INSERT INTO table1 SELECT Large_Data_That_Takes_1_Hr_To_Insert; psql> COMMIT;

場合によっては、BEGIN ステートメントの後にプライマリ DB クラスターとセカンダリ DB クラスターの間でネットワークが切断されることがあります。その場合は、セカンダリ DB クラスターの replication_lag_in_msec 値が増加し始めます。INSERT ステートメントの終了時は、replication_lag_in_msec 値は 1 時間です。ただし、プライマリ DB クラスターとセカンダリ DB クラスター間でコミットされたすべてのユーザーデータは同じであるため、rpo_lag_in_msec 値は 0 です。COMMIT ステートメントが完了すると、すぐに rpo_lag_in_msec 値が増加します。