Amazon RDS for Oracle レプリカのレプリカ遅延を診断して解消する – Part 2

本記事は 2026 年 7 月 9 日に公開された「Diagnose and resolve replica lag in Amazon RDS for Oracle replicas – Part 2」を翻訳したものです。

本記事は、Amazon Relational Database Service (Amazon RDS) for Oracle リードレプリカのレプリケーション遅延を減らす方法を扱う 2 回シリーズの後編です。Part 1 では、REDO 圧縮とレプリカ遅延を最適化する設定オプションを紹介しました。

本記事では、次の内容を説明します。

Amazon CloudWatch メトリクスとデータベースビューを使ったレプリカ遅延の監視。
待機イベント分析による一般的な根本原因の特定。
パフォーマンス問題を解消するための段階的なトラブルシューティング手法。

Amazon RDS for Oracle のリードレプリカでレプリカ遅延が発生した場合、迅速な診断と解消が欠かせません。遅延は、災害対策 (DR) の準備態勢の維持に影響し、リードレプリカ上で実行されるレポート用ワークロードでのデータ提供を遅らせ、データベースのメジャー / マイナーバージョンアップグレードといった通常のメンテナンス作業を遅くする可能性があります。

問題の原因が設定、アプリケーションのワークロードパターン、リソース制約のいずれであっても、根本原因を特定し、的を絞った対策を実施するための体系的な手法を紹介します。

前提条件

始める前に、次の条件を満たしていることを確認してください。

Oracle Enterprise Edition (EE) — レプリケーションを担う Oracle Data Guard は Enterprise Edition でのみ利用できるため、リードレプリカではプライマリインスタンスに Enterprise Edition が必要です。
2 つ以上の vCPU を持つ DB インスタンスクラス — レプリケーションプロセスが正しく機能するには十分なコンピューティングリソースが必要です。
適切なライセンス — 読み取り専用モードには Active Data Guard ライセンスが必要ですが、マウントモードのレプリカには不要です。バージョンやライセンスに関する具体的な制限は、「Requirements and considerations for RDS for Oracle replicas」で確認してください。

Amazon RDS for Oracle のレプリケーション遅延のトラブルシューティング

本セクションでは、遅延の特定方法と一般的な原因を扱います。遅延の存在を特定できたら、以降のセクションの手法を使って根本原因を突き止め、対策を実施できます。

レプリカ遅延を特定する方法

レプリカ遅延は、Amazon CloudWatch メトリクスを使うか、Oracle のデータベースビューを直接クエリして特定できます。CloudWatch メトリクスでは遅延を素早く特定でき、データベースビューではより詳細な診断情報が得られます。

Amazon RDS for Oracle では、ReplicaLag CloudWatch メトリクスはリードレプリカインスタンスでのみ利用できます。CloudWatch メトリクスの粒度について詳しくは、CloudWatch metrics のドキュメントを参照してください。

Amazon CloudWatch メトリクス – ReplicaLag

ReplicaLag CloudWatch メトリクスは、リードレプリカでの REDO 適用の遅延を表示します。適用遅延が大きい場合は、リードレプリカ側のリソース制約 (CPU、I/O) や、適用プロセスに影響する同様の問題を示しています。

このメトリクスを表示するには、次の手順に従います。

リードレプリカインスタンスの [Monitoring] タブに移動します。
[CloudWatch] セクションで「ReplicaLag」を検索します。
データベースレベルでの現在のレプリカ遅延を確認します。

ReplicaLag metric on the Monitoring tab of a Read Replica instance in CloudWatch

注: RDS はリードレプリカに非同期の REDO 転送を使用するため、データベースアクティビティがない場合でもレプリカ遅延が 1 秒と表示されることがあります。V$ ビューやアプリケーションテーブルに対して手動でデータベースクエリを実行し、データベースの変更が同期しているか検証できます。

Amazon CloudWatch メトリクス – ReplicaTransportLag

ReplicaTransportLag CloudWatch メトリクスは、プライマリデータベースからリードレプリカへの REDO 転送の遅延を測定します。転送遅延が大きい場合は、通常、ネットワークの問題やプライマリ側のボトルネックを示しています。

このメトリクスを表示するには、次の手順に従います。

リードレプリカインスタンスの [Monitoring] タブに移動します。
[CloudWatch] セクションで「ReplicaTransportLag」を検索します。
データベースレベルでの現在のレプリカ遅延を確認します。

ReplicaTransportLag metric on the Monitoring tab of a Read Replica instance in CloudWatch

2 つのメトリクスを比較すると、遅延が転送の遅れによるものか、適用プロセスのボトルネックによるものかを判断できます。

標準的なデータベースクエリ

レプリカ遅延に関するより詳細な診断情報を得るには、Oracle のデータベースビューを直接クエリできます。公開ドキュメントに記載されているとおり、次のビューがレプリカ遅延の診断に役立ちます。

V$ARCHIVED_LOG。
V$DATAGUARD_STATS。
V$DATAGUARD_STATUS。
V$ARCHIVE_GAP。

遅延に関連するビュー (V$DATAGUARD_STATS、V$DATAGUARD_STATUS、V$ARCHIVE_GAP) をリードレプリカインスタンスでクエリすると、遅延の状態を取得できます。V$ARCHIVED_LOG はプライマリとリードレプリカの両方でクエリでき、インスタンス間のログ状態を比較して特定できます。

注: Amazon RDS for Oracle のマウントモードのリードレプリカでは、データベースがクエリのためにアクセスできないため、リードレプリカ上でデータベースビューをクエリできません。ReplicaLag と TransportLag の CloudWatch メトリクスが遅延の監視情報を提供します。さらに、アラートログをダウンロードして確認することで、レプリケーション遅延や適用の問題を特定できます。

レプリカ遅延を引き起こす一般的な要因

レプリカ遅延の特定方法を理解したところで、本セクションでは一般的な原因を掘り下げます。Amazon RDS for Oracle のレプリカ遅延は、設定の問題、アプリケーションのワークロードパターン、外部要因という 3 つの主要なカテゴリから生じます。

設定の問題

インフラストラクチャとデータベースの設定は、レプリケーションのパフォーマンスに重要な役割を果たします。一般的な設定の問題としては、REDO ログやスタンバイログのサイズが不足または過小であること、メモリ設定が想定水準に達していないこと、プライマリやリードレプリカのデータベースワークロードを処理するにはコンピューティングやストレージのリソースが不十分であることが挙げられます。

アプリケーションのワークロードパターン

アプリケーションがデータベースとやり取りする方法は、レプリケーションのパフォーマンスに大きく影響します。バッチジョブや高並行性ワークロードといった大量の処理は過剰な REDO を生成し、レプリカが追従する能力を圧倒することがあります。同様に、リードレプリカ上で実行される読み取り集約型のクエリは、コンピューティングとストレージのリソースを大量に消費し、適用プロセスを遅くする可能性があります。

データベース設計の選択も遅延の一因になります。過剰なコミットは REDO 生成を増やし、特権ユーザー (SYS、SYSTEM、RDS_DATAGUARD、rdsdb) の操作を制限するトリガーは内部のレプリケーションプロセスを妨げる恐れがあります。

外部要因

ネットワークレイテンシーもレプリカ遅延の一因になり、特にリージョン間リードレプリカで顕著です。本シリーズの Part 1 では、ネットワークレイテンシーに関連する遅延への対処方法を詳しく説明しています。

レプリカ遅延のトラブルシューティング

前述の方法でレプリカ遅延の存在を特定できたら、次のステップは根本原因の判断です。根本原因はプライマリインスタンスまたはリードレプリカインスタンスのいずれかで生じます。

Amazon RDS for Oracle でレプリカ遅延のトラブルシューティングや根本原因の特定を行う際は、プライマリとリードレプリカの両方のインスタンスで CloudWatch Database Insights (DBI) と拡張モニタリング (EM) を 1 秒粒度で有効にすることをお勧めします。これらのツールを使うと、システム負荷をほぼリアルタイムで能動的に検証でき、CloudWatch メトリクスの 1 分粒度よりも細かい情報が得られます。

通常、レプリカ遅延の根本原因は、遅延が増加し始めた時点で発生していたイベントに関係しています。その時間帯 (5～10 分以内) の DBI と EM のグラフを評価すると、システムで何が変化したかが明らかになることがよくあります。データベースの待機イベントとリソース競合を相関させることで、問題を特定し、緩和または解消するための適切な対策を講じられます。

注: 遅延が増加したときに固有の異常が見当たらない場合は、遅延のある期間とない期間で Active Session History (ASH) または Automatic Workload Repository (AWR) レポートを比較し、差分を特定します。リードレプリカ向けの AWR レポートの生成方法については、Generate AWR reports for Amazon RDS for Oracle read replicas を参照してください。

レプリカ遅延のトラブルシューティングでは、データベースの待機イベントを特定すると根本原因を突き止めやすくなります。待機イベントは、期待されるデータベースアクティビティがないのに、データベースがどこで時間を費やしたりリソースを保持したりしているかを示します。次の待機イベントは、レプリカ遅延と関連することが多いものです。

Data Guard プロセスの待機イベント

これらの待機イベントは、V$DATAGUARD_PROCESS をクエリして監視できます。

Log Network Server (LNS) wait on SENDREQ または ARCH wait on SENDREQ。
Managed Recovery Process (MRP) wait on archivelog arrival または WAIT_FOR_LOG。

セッションレベルの待機イベント

これらの待機イベントはデータベースセッションに影響し、V$SESSION をクエリして監視できます。

log file sync。
db file sequential read / db file scattered read / db file parallel write。
CPU 関連の待機、または高い DB CPU 時間。

これらの待機イベントは、直接的または間接的にレプリカ遅延と関係しています。特定した根本原因に基づき、適切な対策を講じてこれらの待機イベントを排除 / 減少させ、レプリケーション遅延を減らしてください。

一般的な原因と解決策

REDO ログのサイズが不十分

archive_lag_target パラメータは、ログスイッチの発生頻度を制御します。このパラメータは、ログスイッチが強制されるまでの最大時間 (秒) を指定します。Amazon RDS for Oracle では最大値は 300 秒で、Oracle 本来の最大値である 7200 秒 (2 時間) とは大きく異なります。この Amazon RDS for Oracle 固有の制限により、1 時間あたり少なくとも 12 回のログスイッチが発生します。REDO ログがワークロードに対して小さすぎると、ログスイッチが頻繁に発生しすぎます。頻繁なログスイッチにより、チェックポイントの増加と I/O スパイクが生じ、プライマリとリードレプリカの両方を圧迫する可能性があります。

次のクエリを使って、1 時間あたりのアーカイブログ生成量を特定します。

alter session set nls_date_format = 'DD-MON-YYYY HH24:MI:SS';
select trunc(COMPLETION_TIME,'HH') TIME,
       round(sum(BLOCKS*BLOCK_SIZE)/1024/1024/1024) REDO_GENERATED_IN_GB,
       count(*) GENERATION_COUNT from v$archived_log
group by trunc(COMPLETION_TIME,'HH') order by 1 ;

このクエリは、1 時間あたりの REDO 生成量とログスイッチ頻度を時系列で示し、ピーク時間帯を特定して、現在の REDO ログサイズが適切かどうかを判断するのに役立ちます。

注: Amazon RDS for Oracle インスタンスでは ALTER SYSTEM/DATABASE コマンドが制限されているため、Oracle DB インスタンスで一般的なログ関連タスクを実行する AWS ドキュメントに従い、RDSADMIN パッケージを使って必要な REDO ログ関連の作業を行ってください。

ワークロードに対するシステム構成の不足

リソースのスロットリングは、コンピューティングレベル (CPU、メモリ、ネットワーク帯域幅) やストレージレベル (IOPS/スループット) で発生する可能性があります。プライマリやリードレプリカに十分なリソースがないと、レプリケーションプロセスが他のデータベース操作と競合し、遅延を引き起こします。

注: スループットのスロットリングはネットワークレベルでも発生し得るため、ワークロード向けに選択したコンピューティングが、アプリケーションのワークロードを支えるベースライン帯域幅を備えているか確認してください。

ストレージレベルのリソーススロットリングが発生している場合、通常は読み取り / 書き込みのレイテンシーが 10 ミリ秒を超えます。スロットリングされている値に応じて IOPS/スループットを増やせば、問題を緩和 / 解消できます。

DBI で CPU 使用率が割り当て済みの最大 vCPU を超えていないか確認してください。また、前述の待機イベントがソースまたはターゲットのいずれかで DBI に現れていないかも確認します。プライマリとリードレプリカが同じコンピューティングおよびストレージ構成であることを確認してください。これにより、レプリカがソースからのピーク負荷を処理できるようになります。

注: 高い CPU 使用率は、直接的な負荷から生じることもあれば、リソースのスロットリングから間接的に生じることもあります (たとえば、Amazon Elastic Block Store (EBS) の IOPS 上限によりサーバープロセスが待機し、CPU 使用率が上がる場合など)。したがって、関連する根本原因を修正すれば、CPU 消費を割り当て済み vCPU 以下に抑えられます。

シナリオ: レプリカ遅延を段階的にトラブルシューティングする

次のシナリオでは、増加するレプリカ遅延の原因を特定し、絞り込む方法を示します。

ステップ 1: CloudWatch でレプリカ遅延を確認し、遅延の開始時刻を特定する

リードレプリカインスタンスの [Monitoring] タブに移動して、ReplicaLag メトリクスを表示します。「ReplicaLag」グラフで [Maximize] を選択し、正確な開始時刻を特定します。

この例では、スナップショットは 1 月 5 日の 18:00 UTC に取得されました。グラフを見ると、レプリカ遅延は 17:50 UTC 頃から増加し始めています。遅延は数分前に始まり、現在 9.15 秒に達しています。

ReplicaLag graph showing lag beginning to climb around 17:50 UTC, reaching 9.15 seconds

ステップ 2: プライマリで DBI を確認する

AWS マネジメントコンソールでプライマリデータベースインスタンスに移動します。

[Monitoring] → [Database Insights] を選択します。デフォルトのビューには直近 3 時間が表示されます。

Database Insights view for the primary instance showing the default last 3 hours

右上隅の [Custom] を選択し、分析に適した時間範囲を選びます。

Custom time range selector in Database Insights for choosing the analysis window

ステップ 3: 転送遅延と適用遅延を比較する

「レプリカ遅延を特定する方法」セクションで説明したとおり、AWS マネジメントコンソールでリードレプリカのモニタリングセクションにある ReplicaLag と ReplicaTransportLag の遅延メトリクスを確認します。

ReplicaLag and ReplicaTransportLag metrics compared in the Read Replica monitoring view

CloudWatch メトリクスで ReplicaTransportLag と ReplicaLag のメトリクスを比較し、ボトルネックがどこにあるかを判断します。

シナリオ	示す内容
TransportLag が高く、ApplyLag が同程度	問題は REDO の送信であり、適用ではない
TransportLag が正常で、ApplyLag が高い	レプリカでの適用プロセスのボトルネック
両方のメトリクスが高いが値が異なる	詳細な分析が必要

このシナリオでは、Transport Lag と Apply Lag がほぼ同じであり、ボトルネックが適用プロセスではなく REDO の生成 / 送信にあることを示しています。

ステップ 4: リードレプリカで MRP プロセスの状態を確認する

リードレプリカで V$MANAGED_STANDBY をクエリして、Managed Recovery Process の状態を確認します。

SQL> SELECT PROCESS, STATUS, SEQUENCE#, BLOCK#
  FROM V$MANAGED_STANDBY
  WHERE PROCESS = 'MRP0';

PROCESS   STATUS        SEQUENCE#   BLOCK#
--------- ------------- ----------- ----------
MRP0      APPLYING_LOG  15844       259554

現在、MRP プロセスの状態を見ると、ログを適用中であることが示されています。次のステップとして、プライマリで生成されたログシーケンスを確認する必要があります。

SQL> select thread#,max(sequence#) from v$log_history group by thread#;

THREAD#   MAX(SEQUENCE#)
--------- --------------
1         15863

ここで、適用済みのログとプライマリで生成されたログを比較すると、19 のログシーケンスのギャップがあることがわかります。これは REDO の大量生成が原因である可能性があります。過去 1 時間に生成された REDO を確認して、生成状況を把握する必要があります。

SQL> ALTER SESSION SET NLS_DATE_FORMAT = 'DD-MON-YYYY HH24:MI:SS';

Session altered.

SQL> SELECT TRUNC(COMPLETION_TIME, 'HH24') AS COMPLETION_TIME,
  SUM(BLOCKS * BLOCK_SIZE) / (1024 * 1024 * 1024) AS GENERATED_GB,
  COUNT(*) AS LOG_COUNT
  FROM V$ARCHIVED_LOG
  WHERE DEST_ID = 1
  AND COMPLETION_TIME >= SYSDATE - 1/24
  GROUP BY TRUNC(COMPLETION_TIME, 'HH24')
  ORDER BY 1;

COMPLETION_TIME       GENERATED_GB   LOG_COUNT
--------------------- -------------- ----------
05-JAN-2026 17:00:00  2.54819012     21
05-JAN-2026 18:00:00  40.2287965     326
SQL>

これは、過去 1 時間に 40 GB の REDO が生成されたことを示しています。分析に応じて COMPLETION_TIME フィルターを適宜変更してください。

注: アラートログが、ORA-16055: FAL request rejected や ORA-16401: archivelog rejected by RFS のように、レプリカ遅延が発生している理由に関する重要な手がかりを与えてくれることがあります。そのような場合は、関連する My Oracle Support ノートを確認して次のステップを判断してください。

ステップ 5: プライマリインスタンスのメトリクスを分析する

1 月 5 日 17:50～18:00 UTC のこのシナリオでは、DBI アラームが自動的に次を捕捉しました。

読み取りおよび書き込みレイテンシーが 10 ミリ秒を超過。

DBI alarm showing read and write latency above 10 milliseconds on the primary

DB Load Analysis は、最も CPU (5 vCPU) を消費している UPDATE ステートメントを示しています。

DB Load Analysis showing an UPDATE statement consuming the most CPU at 5 vCPUs

Top Waits セクションは、レプリカ遅延が始まった時間帯にデータベースで発生した上位 2 つの待機イベントとして、log file switch (checkpoint incomplete) と log file switch completion を示しています。

Top Waits section showing log file switch (checkpoint incomplete) and log file switch completion as the top wait events

Database Telemetry Metrics は、17:55 UTC 頃に I/O 操作が大きくスパイクしたことを示しています。

Database Telemetry Metrics showing a spike in I/O operations around 17:55 UTC

CloudWatch メトリクスは、読み取り + 書き込み IOPS が Amazon RDS プライマリデータベースに割り当てられた 3,000 IOPS を超えていることを裏付けています。

CloudWatch metrics showing combined read and write IOPS exceeding the allocated 3,000 IOPS on the primary database

CloudWatch IOPS graph confirming the primary database is exceeding its 3,000 IOPS allocation

ステップ 6: Database Insights でリードレプリカを分析する

1 月 5 日 17:50～18:00 UTC のリードレプリカを DBI で確認します。

Read Replica view in Database Insights where the top SQL appears as unknown

上位の SQL は unknown と表示されています。これは通常、リソースを消費しているプロセスが SQL_ID を持たない場合に発生します。このような状況では、リソースを消費している OS プロセスのプロセス ID (PID) を特定し、そのプロセスが何を実行しているかを調べられます。

ステップ 7: CPU を最も消費しているプロセスを特定する

消費しているプロセスを特定するには、次の手順に従います。

[Database Telemetry] → [OS Processes] に移動します。

CPU % で並べ替えます。

OS Processes view sorted by CPU showing ora_pr00_ORCL as the top consumer

このシナリオでは、CPU を最も消費しているプロセスは ora_pr00_ORCL で、プロセス ID は 751957、CPU を 3.31% 消費しています。このプロセス名は、ターゲット上で REDO ログの変更を並列に適用する Parallel Recovery (PR) ワーカープロセスであることを示しています。

ステップ 8: 問題を修正または緩和するための推奨アクション

ストレージ負荷に対応するため EBS IOPS を増やす。
ログスイッチ頻度を減らすため REDO ログサイズを増やす。
バースト処理に必要であれば REDO ログループを追加する。
変更を実施する前に、アプリケーションチームおよびビジネスチームと連携して負荷パターンを確認する。

シナリオ: リードレプリカでの適用側のボトルネック

次のシナリオでは、プライマリやネットワークではなく、リードレプリカの適用パスのボトルネックによって生じるレプリカ遅延を特定する方法を示します。この例では、プライマリで大量の UPDATE ワークロードが実行されており、それがリードレプリカでの適用 I/O 需要を押し上げています。

ステップ 1: ReplicaLag と ReplicaTransportLag を比較する

リードレプリカインスタンスの [Monitoring] タブに移動し、同じ時間帯の ReplicaLag と ReplicaTransportLag を並べて表示します。

ReplicaLag climbing while ReplicaTransportLag stays under 35 seconds in the Read Replica monitoring view

この例では、ReplicaLag は 2026-05-02 15:00 UTC に増加し始め、約 2 時間まで拡大する一方で、ReplicaTransportLag は終始 35 秒未満にとどまっています。前のシナリオの比較表によれば、このパターン (TransportLag が正常で ApplyLag が高い) は、リードレプリカでの適用プロセスのボトルネックを示しています。

ステップ 2: データベースレベルで遅延パターンを確認する

リードレプリカで V$DATAGUARD_STATS をクエリして、CloudWatch のビューを裏付けます。

SQL> SELECT NAME, VALUE, DATUM_TIME FROM V$DATAGUARD_STATS
  2 WHERE NAME IN ('transport lag', 'apply lag');

NAME            VALUE             DATUM_TIME
--------------- ----------------- -------------------
transport lag   +00 00:00:00      05/03/2026 03:23:47
apply lag       +00 02:01:05      05/03/2026 03:23:47

転送遅延がゼロである一方で適用遅延は 2 時間を超えており、ボトルネックが適用側にあることを裏付けています。

プライマリの現在のログシーケンスと、リードレプリカで MRP が適用しているシーケンスを比較します。

-- On the primary
SQL> SELECT thread#, MAX(sequence#) FROM v$log_history GROUP BY thread#;

THREAD#   MAX(SEQUENCE#)
--------- --------------
1         97565

-- On the Read Replica
SQL> SELECT PROCESS, STATUS, SEQUENCE#, BLOCK#
  2 FROM V$MANAGED_STANDBY WHERE PROCESS = 'MRP0';

PROCESS   STATUS        SEQUENCE#   BLOCK#
--------- ------------- ----------- ----------
MRP0      APPLYING_LOG  97540       90708

MRP はプライマリより 25 のログシーケンス遅れており、V$DATAGUARD_STATS が報告する 2 時間の適用遅延と一致します。

ステップ 3: Database Insights でリードレプリカの待機イベントを分析する

Database Insights でリードレプリカを開き、同じ時間帯の Waits で分割した Database load を確認します。

Database load on the Read Replica sliced by Waits, dominated by I/O-related apply waits starting at 15:00 UTC

15:00 UTC 以降、平均アクティブセッションは約 6 に跳ね上がり、I/O 関連の待機が大半を占めています。control file sequential read、checkpoint completed、db file async I/O submit、parallel recovery read buffer free、Data Guard server operation complete などです。これらはすべて適用 / メディアリカバリのパス上にあり、リードレプリカが REDO の変更を十分な速さで永続化できていないことを示しています。

ステップ 4: リードレプリカのストレージメトリクスを確認する

ReplicaLag が増加し始めたのと同じ時刻の、リードレプリカボリュームの BurstBalance と WriteIOPS を確認します。

BurstBalance metric for the Read Replica volume dropping to 0% at 14:59 UTC

WriteIOPS for the Read Replica volume flatlining at about 300 from 15:00 UTC after burst credits are exhausted

BurstBalance は 14:59 UTC に 0% まで低下し、WriteIOPS は 15:00 UTC 以降、約 300 で頭打ちになっています。ReplicaLag も同じ分に上昇し始めます。gp2 ボリュームがバーストクレジットを使い果たし、ベースライン IOPS にスロットリングされたため、MRP と並列リカバリワーカーはすべての書き込みで待機せざるを得なくなっています。

ステップ 5: 根本原因

REDO はリードレプリカに正常に送信されていますが (ReplicaTransportLag は低い)、ボリュームがバーストクレジットを使い果たすと、レプリカのストレージが適用 I/O に追従できなくなります。このため、未適用の REDO によるバックログが増大します。

ステップ 6: 問題を修正または緩和するための推奨アクション

リードレプリカのストレージを、持続的な適用ワークロードに合わせてサイジングしたプロビジョンド IOPS を備える gp3 または io1/io2 に切り替えるか、gp2 ボリュームのサイズを増やしてベースライン IOPS をレプリカの適用レート以上に引き上げます。
リードレプリカのストレージをプライマリとは独立してサイジングします。持続的な適用には、プライマリのワークロードと同等かそれ以上の書き込みスループットが必要になることがあります。
BurstBalance と ReplicaLag に CloudWatch アラームを設定し、クレジットが枯渇する前に通知を受け取れるようにします。

クリーンアップ

本記事に沿って AWS リソースをデプロイしたり設定を変更したりした場合は、それらの変更を必ず削除または元に戻してください。

まとめ

Amazon RDS for Oracle リードレプリカのレプリケーション遅延は、アプリケーションのパフォーマンスと災害対策の準備態勢に影響を与える可能性があります。Database Insights と拡張モニタリングを有効にし、一般的な待機イベントを理解し、本記事で説明したトラブルシューティングの手法に従うことで、根本原因を素早く特定し、適切な対策を実施できます。これらの手法で解決しない複雑なシナリオについては、AWS Support または Oracle ベンダーサポートに連絡して追加の支援を受けてください。

著者について

この記事はSolutions Architect の矢木覚が翻訳しました。

Amazon Web Services ブログ