Amazon Aurora Global Database のモニタリング - Amazon Aurora

Amazon Aurora Global Database のモニタリング

Aurora Global Database を構成している Aurora DB クラスターを作成するときは、DB クラスターのパフォーマンスをモニタリングできる多くのオプションを選択できます。オプションは以下のとおりです。

  • Amazon RDS Performance Insights -基盤となる Aurora データベースエンジンで Performance Schema を有効にします。Performance Insights と Aurora Global Database の詳細については、「Amazon RDS Performance Insights を使用した Amazon Aurora Global Database のモニタリング」を参照してください。

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

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

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

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

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

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


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

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

Amazon RDS Performance Insights を使用した Amazon Aurora Global Database のモニタリング

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

Performance Insights が作成したレポートは、グローバルデータベースの各クラスターに適用されます。既に Performance Insights を使用している Aurora Global Database に新しいセカンダリ 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 を使用したDB 負荷のモニタリング」を参照してください 。

データベースアクティビティストリーミングを使用した Aurora グローバルデータベースのモニタリング

データベースアクティビティストリーム機能を使用して、グローバルデータベース内の DB クラスターの監査活動を監視し、アラームを設定することができます。DB クラスターでデータベースアクティビティストリーミングを個別に開始します。各クラスターは、独自の AWS リージョン 内の独自の Kinesis ストリーミングに監査データを配信します。詳細については、「データベースアクティビティストリーミングを使用した Amazon Aurora のモニタリング」を参照してください。

Aurora PostgreSQL ベースの Aurora Global Database のモニタリング

グローバルデータベースのステータスを表示するには、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 Global Database への接続」を参照してください。

  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 リージョン をエンジン別にリスト化した表については、「Regions and Availability Zones」(リージョンとアベイラビリティーゾーン) を参照してください。

    • 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_time - durability_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 リージョン をエンジン別にリスト化した表については、「Regions and Availability Zones」(リージョンとアベイラビリティーゾーン) を参照してください。

    • 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 値が増加します。