Amazon Aurora リードレプリカが遅れ、再起動されたのはなぜですか?

最終更新日: 2022 年 7 月 10 日

Amazon Aurora DB のプロダクションクラスターを実行しているのですが、リーダーインスタンスが「リードレプリカがマスターに対して相当な遅れを取っています。MySQL を再起動しています」または「リードレプリカがマスターに対して相当な遅れを取っています。postgres を再起動しています」というエラーで再起動されました。リーダーが再起動されたのはなぜですか?

簡単な説明

AuroraReplicaLag は、Aurora DB クラスター内のライター Aurora DB インスタンスからリーダーインスタンスに変更をレプリケーションする際の遅延をミリ秒単位で測定したものです。Aurora レプリカは、ライターインスタンスと同じストレージボリュームに接続します。ライターインスタンスとリーダーインスタンスの間の遅延は、Amazon CloudWatch の AuroraReplicaLag メトリクスを使用して測定できます。

Aurora DB クラスターの場合は、AuroraReplicaLag メトリクスが、ライター DB インスタンスと比較した Aurora レプリカのデータキャッシュ (バッファプールまたはページキャッシュ) の遅延を示します。変更は、共有ストレージボリュームに同期的に書き込まれますが、読み取りの整合性のために変更に関連するメモリにキャッシュされたすべてのデータが無効になるリーダーインスタンスには非同期的にレプリケートされます。場合によっては、リーダーインスタンス全体で変更を伝播するときに遅延が生じることがあります。この遅延は CloudWatch の AuroraReplicaLag メトリクスにおける増加として表面化し、これが最終的に再起動を引き起こす可能性があります。

AuroraReplicaLag に関するほぼリアルタイムのメタデータを測定できます。

Amazon Aurora MySQL - 互換エディションの場合、INFORMATION_SCHEMA.REPLICA_HOST_STATUS の表から選択します。

mysql> 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() 関数を呼び出して、その結果をフィルタリングします。

postgres=> 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)

注: この記事で提供されるソリューションは、マルチリージョンのグローバルデータベースクラスターではなく、単一リージョンの Amazon Aurora クラスターに適用されます。

解決方法

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

リーダーインスタンスの DB インスタンスクラス設定がライター DB インスタンスのものよりも緩やかな場合は、リーダーがキャッシュで無効化を行ってから遅れを取り戻すには変更の量が多すぎる可能性があります。このシナリオでは、Aurora クラスター内のすべての DB インスタンスの仕様を同じにすることがベストプラクティスです。

メトリクスと拡張モニタリングを使用したセッションのモニタリング

リーダーインスタンスでは、複数のセッションが同時に実行されているときに遅延が発生することがあります。Aurora レプリカは、利用可能なリソースがないため、ライターから必要な変更を適用するのに時間がかかることがあります。このタイムラグは、CPUUtilization、DBConnections、および NetworkReceiveThroughput などのメトリクスで確認することができます。また、1 秒または 5 秒の粒度で拡張モニタリングを有効にして、リーダーのリソース使用量を把握することもできます。また、Performance Insights を使用してワークロードを視覚化することも可能です。さらに、Aurora PostgreSQL - 互換の場合のみ、 ReadIOPS メトリクスを使用します。

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

既に書き込み負荷が高いプロダクションクラスターでの書き込みアクティビティの急激な増加は、ライター DB インスタンスに過剰な負荷がかかる原因となり得ます。サージによって引き起こされる追加の負荷が、1 つ以上のリーダーインスタンスの遅れを引き起こす場合があります。これは、DMLThroughput、DDLThroughput、および Queries メトリクスの急増が示される Amazon CloudWatch で確認できます。

Aurora PostgreSQL の場合は、WriteThroughput メトリクスでこれを確認できます。

増大化が進む History List Length (HLL) を調べる (Aurora MySQL - 互換)

MySQL InnoDB エンジンには、デフォルトで MVCC (multi-version concurrency control) が組み込まれています。これは、トランザクションの全体を通じて、影響を受けるすべての行で発生したすべての変更を追跡する必要があることを意味します。長時間実行されるトランザクションが完了すると、パージスレッドアクティビティの急増が始まります。長時間実行されるトランザクションによって作成されるバックログの量が原因で、この突然のパージが Aurora レプリカの遅延を引き起こす場合があります。

Aurora MySQL には、バージョン 1.19.2、および 2.06 以降から RollbackSegmentHistoryListLength メトリクスが含まれています。このパージは、CloudWatch でこのメトリックスを使用して確認できます。これは、SHOW ENGINE INNODB STATUS の出力や、または以下のように情報スキーマをクエリすることで表示することもできます。

mysql> 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)

このメトリクスを監視する CloudWatch アラームをセットアップして、その数値が高くなりすぎないようにしてください。リレーショナルデータベースでは、長時間実行されるトランザクションを避けることがベストプラクティスです。

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

まれではありますが、ライターインスタンスとリーダーインスタンスの間、またはインスタンスと Aurora ストレージ層の間で、一時的なネットワーク通信障害が発生する場合があります。リーダーインスタンスは、ネットワークにおける短時間の中断により、遅れたり、再起動したりすることがあります。また、Aurora レプリカは、大量の変更によってインスタンスのネットワーク帯域幅が飽和状態になることが原因で遅れる可能性があります。この問題を回避するベストプラクティスは、DB インスタンスのサイズ、ひいてはそのネットワーク機能を検討することです。