Amazon Aurora Global Database のモニタリング - Amazon Aurora
Performance Insights を使用した Aurora Global Database のモニタリングデータベースアクティビティストリーミングを使用した Aurora グローバルデータベースのモニタリングAurora MySQL ベースのグローバルデータベースのモニタリングAurora PostgreSQL ベースのグローバルデータベースのモニタリング

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 のプロセスまたはスレッド使用率のメトリクスを生成します。強化モニタリングの詳細については、「拡張モニタリングを使用した OS メトリクスのモニタリング」を参照してください。

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

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

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

  • Aurora MySQL ベースのグローバルデータベースの場合、特定の information_schema テーブルを使用して、Aurora Global Database とそのインスタンスのステータスを確認することができます。この方法の詳細は、Aurora MySQL ベースのグローバルデータベースのモニタリングを参照してください。

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

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

[モニタリング] タブ: [CloudWatch]、[強化モニタリング]、[OS プロセスリスト]、および [パフォーマンスインサイト] オプションを示している [モニタリング] ドロップダウン。

詳細については、「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 MySQL ベースのグローバルデータベースのモニタリング

Aurora MySQL ベースのグローバルデータベースのステータスを表示するには、information_schema.aurora_global_db_status および information_schema.aurora_global_db_instance_status テーブルをクエリします。

注記

information_schema.aurora_global_db_status および information_schema.aurora_global_db_instance_status テーブルは、Aurora MySQL バージョン 3.04.0 以降のグローバルデータベースでのみ使用できます。

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

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

  2. mysql コマンドで information_schema.aurora_global_db_status テーブルをクエリして、プライマリボリュームとセカンダリボリュームを一覧表示します。このクエリは、次の例のように、グローバルデータベースのセカンダリ DB クラスターのラグタイムを返します。

    mysql> select * from information_schema.aurora_global_db_status;
    AWS_REGION | HIGHEST_LSN_WRITTEN | DURABILITY_LAG_IN_MILLISECONDS | RPO_LAG_IN_MILLISECONDS | LAST_LAG_CALCULATION_TIMESTAMP | OLDEST_READ_VIEW_TRX_ID
-----------+---------------------+--------------------------------+------------------------+---------------------------------+------------------------
us-east-1  |           183537946 |                            0   |                      0 |  1970-01-01 00:00:00.000000     |               0
us-west-2  |           183537944 |                            428 |                      0 |  2023-02-18 01:26:41.925000     |               20806982
(2 rows)

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

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

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

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

    • DURABILITY_LAG_IN_MILLISECONDS – セカンダリ DB クラスターの HIGHEST_LSN_WRITTEN とプライマリ DB クラスターの HIGHEST_LSN_WRITTEN とのタイムスタンプ値の差。この値は、Aurora グローバルデータベースのプライマリ DB クラスターでは常に 0 です。

    • RPO_LAG_IN_MILLISECONDS - 目標復旧時点 (RPO) のラグ。RPO 遅延とは、最近のユーザートランザクション COMMIT が、Aurora グローバルデータベースのプライマリ DB クラスターに保存された後、セカンダリ DB クラスターに保存されるまでにかかる時間です。この値は、Aurora グローバルデータベースのプライマリ DB クラスターでは常に 0 です。

      簡単に言うと、このメトリクスは、Aurora グローバルデータベース内の各 Aurora MySQL DB クラスターの目標復旧時点、つまり、障害が発生した場合に失われる可能性のあるデータの量を計算します。遅延と同様に、RPO は時間単位で測定されます。

    • LAST_LAG_CALCULATION_TIMESTAMP - DURABILITY_LAG_IN_MILLISECONDS および RPO_LAG_IN_MILLISECONDS に対して値が最後に計算されたタイムスタンプ。1970-01-01 00:00:00+00 のような時間値は、これがプライマリ DB クラスターであることを意味します。

    • OLDEST_READ_VIEW_TRX_ID - ライター DB インスタンスがパージできる最も古いトランザクションの ID。

  3. information_schema.aurora_global_db_instance_status テーブルにクエリして、プライマリ DB クラスターとセカンダリ DB クラスターの両方のセカンダリ DB インスタンスをすべて一覧表示します。

    mysql> select * from information_schema.aurora_global_db_instance_status;
    SERVER_ID            |              SESSION_ID              | AWS_REGION | DURABLE_LSN | HIGHEST_LSN_RECEIVED | OLDEST_READ_VIEW_TRX_ID | OLDEST_READ_VIEW_LSN | VISIBILITY_LAG_IN_MSEC
---------------------+--------------------------------------+------------+-------------+----------------------+-------------------------+----------------------+------------------------
ams-gdb-primary-i2   | MASTER_SESSION_ID                    | us-east-1  | 183537698   |                    0 |                       0 |                    0 |                      0
ams-gdb-secondary-i1 | cc43165b-bdc6-4651-abbf-4f74f08bf931 | us-west-2  | 183537689   |            183537692 |                20806928 |            183537682 |                      0
ams-gdb-secondary-i2 | 53303ff0-70b5-411f-bc86-28d7a53f8c19 | us-west-2  | 183537689   |            183537692 |                20806928 |            183537682 |                    677
ams-gdb-primary-i1   | 5af1e20f-43db-421f-9f0d-2b92774c7d02 | us-east-1  | 183537697   |            183537698 |                20806930 |            183537691 |                     21
(4 rows)

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

    • SERVER_ID - DB インスタンスのサーバー識別子。

    • SESSION_ID - 現在のセッションの一意識別子。MASTER_SESSION_ID の値は、Writer (プライマリ) DB インスタンスを識別します。

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

    • DURABLE_LSN - ストレージで耐久性の高い LSN。

    • HIGHEST_LSN_RECEIVED - ライター DB インスタンスから DB インスタンスが受信した最高の LSN。

    • OLDEST_READ_VIEW_TRX_ID - ライター DB インスタンスがパージできる最も古いトランザクションの ID。

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

    • VISIBILITY_LAG_IN_MSEC — プライマリ DB クラスターのリーダーの場合、この DB インスタンスがライター DB インスタンスよりどれだけ遅れているか (ミリ秒単位)。セカンダリ DB クラスターのリーダーの場合、この DB インスタンスがセカンダリボリュームからどれだけ遅れているかをミリ秒単位で示します。

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

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

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

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

Aurora PostgreSQL ベースのグローバルデータベースのステータスを表示するには、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 クラスターの durability_lag_in_msec 値が増加し始めます。INSERT ステートメントの終了時は、durability_lag_in_msec 値は 1 時間です。ただし、プライマリ DB クラスターとセカンダリ DB クラスター間でコミットされたすべてのユーザーデータは同じであるため、rpo_lag_in_msec 値は 0 です。COMMIT ステートメントが完了すると、すぐに rpo_lag_in_msec 値が増加します。