Aurora リードレプリカが遅れて再起動する原因となる問題のトラブルシューティング方法を教えてください。

解決策

注: 次の解決策は、単一の AWS リージョン内の Aurora クラスターとグローバルデータベースプライマリクラスターに適用され、グローバルデータベースのセカンダリクラスターには適用されません。

AuroraReplicaLag の測定

Aurora レプリカは、ライターインスタンスと同じストレージボリュームに接続します。Aurora は共有ストレージボリュームに変更を同期的に書き込みますが、リーダーインスタンスに変更を非同期でレプリケートします。読み取りの一貫性を保つため、Aurora は変更に関連するメモリにキャッシュされているデータを無効にします。データキャッシュには、バッファープールまたはページキャッシュが含まれます。

場合によっては、リーダーインスタンス全体に変更を伝播する際に遅延が発生することがあります。この遅延は、再起動の原因となる可能性がある Amazon CloudWatch の AuroraReplicaLag メトリクスの増加として表示され、次のエラーメッセージが表示される場合があります。

"Read Replica has fallen behind the master too much.Restarting".

Amazon Aurora MySQL 互換エディションの場合は、INFORMATION_SCHEMA.REPLICA_HOST_STATUS テーブルで次のクエリを実行して AuroraReplicaLag を測定してください。

select server_id AS Instance_Identifier, if(session_id = 'MASTER_SESSION_ID', 'writer', 'reader') as Role, replica_lag_in_milliseconds as AuroraReplicaLag from information_schema.replica_host_status;

出力例:

+---------------------+--------+-------------------+  
| Instance_Identifier | Role   | AuroraReplicaLag  |  
+---------------------+--------+-------------------+  
| myamscluster-aza-1  | writer |                 0 |  
| myamscluster-azb-1  | reader | 5.150000095367432 |  
| myamscluster-aza-2  | reader | 5.033999919891357 |  
+---------------------+--------+-------------------+

Amazon Aurora PostgreSQL 互換エディションの場合は、次のクエリを実行して aurora_replica_status() 関数を取得し、結果をフィルタリングします。

select server_id, case when session_id= 'MASTER_SESSION_ID' then 'Writer' else 'Reader' end AS Role, replica_lag_in_msec as AuroraReplicaLag from aurora_replica_status();

出力例:

server_id          | role   | aurorareplicalag  
-------------------+--------+------------------  
myapgcluster-aza-1 | Reader | 19.641  
myapgcluster-azb-1 | Reader | 19.752  
myapgcluster-aza-2 | Writer |  
(3 rows)

クラスター内のすべてのインスタンスの仕様が同じであることを確認してください

リーダーインスタンスの DB インスタンスクラス設定がライター DB インスタンスよりも低い場合、変更の数が多すぎる可能性があります。その場合、リーダーインスタンスはキャッシュ内で無効にできなくなります。この問題を回避するため、Aurora クラスターのすべての DB インスタンスで同じ仕様を維持することをお勧めします。

メトリクスと拡張モニタリングによるセッションの監視

複数のセッションを同時に実行している場合、リーダーインスタンスは遅延する可能性があります。Aurora レプリカでは、利用可能なリソースが不足しているため、ライターから必要な変更がゆっくりと適用される場合があります。遅延を確認するには、CPUUtilization、DBConnections、NetworkReceiveThroughput の各メトリクスを表示します。また、1 秒または 5 秒単位で拡張モニタリングを有効にして、リーダーのリソース使用状況を確認することもできます。または、Performance Insights を有効にし、Database Insights を使用してリーダーのワークロードを視覚化することもできます。Aurora PostgreSQL 互換については、ReadIOPS メトリクスを使用できます。

重要: 2026 年 6 月 30 日に Performance Insights のサポートは終了します。2026 年 6 月 30 日までに、Database Insights の Advanced モードにアップグレードしてください。アップグレードしない場合、Performance Insights を使用する DB クラスターは、デフォルトで Database Insights の Standard モードを使用します。実行計画とオンデマンド分析は、Database Insights の Advanced モードでのみサポートされます。クラスターがデフォルト設定により Standard モードを使用する場合、コンソールでこれらの機能を使用できない可能性があります。Advanced モードの有効化については、「Amazon RDS で Database Insights の Advanced モードを有効にする」および「Amazon Aurora で Database Insights の Advanced モードを有効にする」を参照してください。

CloudWatch を使用して書き込みアクティビティを視覚化する

すでに書き込みの多い本番クラスターで書き込みアクティビティが突然急増すると、ライター DB インスタンスが過負荷になる可能性があります。過負荷により、リーダーインスタンスが遅延する可能性があります。CloudWatch を使用して、突然のバーストを示す DMLThroughput、DDLThroughput、Queries の各メトリクスを調べます。Aurora PostgreSQL 互換については、WriteThroughput メトリクスを調べてください。

Aurora MySQL 互換の長時間実行トランザクションのトラブルシューティング

MySQL InnoDB エンジンは、デフォルトでマルチバージョン同時実行制御 (MVCC) を使用します。そのため、トランザクション中に発生した行へのすべての変更を追跡する必要があります。長時間実行されているトランザクションが完了すると、パージスレッドのアクティビティが急増します。急なパージは、長時間実行されているトランザクションによって作成されるバックログの量が原因で、Aurora レプリカに遅延を引き起こす可能性があります。

Aurora MySQL 互換の場合は、CloudWatch のRollbackSegmentHistoryListLength メトリクスを確認して、パージの急増があるか調べてください。SHOW ENGINE INNODB STATUS コマンドを実行すると、パージを確認できます。次のクエリを実行します。

select NAME AS RollbackSegmentHistoryListLength, COUNT from INFORMATION_SCHEMA.INNODB_METRICS where NAME = 'trx_rseg_history_len';

出力例:

+----------------------------------+-------+  
| RollbackSegmentHistoryListLength | COUNT |  
+----------------------------------+-------+  
| trx_rseg_history_len             |   358 |  
+----------------------------------+-------+  
1 row in set (0.00 sec)

RollbackSegmentHistoryListLength をモニタリングするように CloudWatch アラームを設定して、高い数値に達していないことを確認します。リレーショナルデータベースでは、長時間実行されるトランザクションを避けることをお勧めします。

短時間のネットワーク中断を防ぐ

まれではありますが、ライターインスタンスとリーダーインスタンス間、またはインスタンスと Aurora ストレージレイヤー間で一時的なネットワーク通信障害が発生する可能性があります。リーダーインスタンスは、ネットワークが短時間中断されたために遅延したり再起動したりすることがあります。Aurora レプリカは、多数の変更によってインスタンスのネットワーク帯域幅が過負荷になったために遅延する場合もあります。この問題を回避するには、DB インスタンスのサイズを、変更回数を処理できるサイズに変更することをお勧めします。

関連情報

DB クラスターに Aurora レプリカを追加する

Amazon Aurora MySQL でのレプリケーション

Amazon Aurora クラスターでのメトリクスのモニタリング

Amazon Aurora のインスタンスレベルのメトリクス