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

最終更新日: 2021 年 2 月 2 日

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

簡単な説明

AuroraReplicaLag は、プライマリ Aurora DB インスタンスから Aurora DB クラスター内のリーダーノードに更新をレプリケーションする際の更新ミリ秒単位の遅延の測定です。Aurora レプリカは、プライマリ DB インスタンスと同じストレージボリュームに接続し、読み取り操作のみをサポートします。プライマリノードとリーダーノード間のタイムラグは、Amazon CloudWatch の AuroraReplicaLag メトリクスを使用して測定できます。

Aurora PostgreSQL DB クラスターの場合は、AuroraReplicaLag メトリクスが、プライマリ DB インスタンスのページキャッシュと比較した Aurora レプリカのページキャッシュのタイムラグを示します。これは、データがクラスターボリュームに書き込まれた後で、データがライターノードとリーダーノードの両方からほぼリアルタイムでアクセス可能になることを意味します。

変更がリーダーノード間で伝播されることを確実にするには、読み込み整合性のためにキャッシュされたデータを無効にする必要があります。場合によっては、リーダーノード全体で変更を伝播するときに遅延が生じることがあります。この遅延は CloudWatch の AuroraReplicaLag メトリクスにおける増加として表面化し、これが最終的に再起動を引き起こします。

Aurora MySQL の場合は、INFORMATION_SCHEMA.REPLICA_HOST_STATUS テーブルを使用して、AuroraReplicaLag に関するほぼリアルタイムのメタデータを測定できます。

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  |
+---------------------+--------+-------------------+
| primary-instance    | writer |                 0 |
| reader-node-02      | reader | 5.150000095367432 |
| reader-node-03      | reader | 5.033999919891357 |
+---------------------+--------+-------------------+

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
-------------+--------+------------------
read-node-01 | Reader | 19.641
read-node-02 | Reader | 19.752
primary-node | Writer |
(3 rows)

解決方法

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

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

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

リーダーノードでは、複数のセッションが同時に実行されているときにタイムラグが発生する場合があります。Aurora レプリカでは、利用可能なリソースが不十分であることから、プライマリ由来の必要な変更の適用に時間がかかる場合があります。このタイムラグは、CPUUtilization、DBConnections、NetworkReceiveThroughput、および ActiveTransactions などのメトリクスで確認することができます。

Aurora PostgreSQL の場合は、ActiveTransactions の代わりに ReadIOPS メトリクスを使用します。リーダーノードの使用状況を理解するために、拡張モニタリングを有効化して、その粒度を少なくとも 5/1 秒に設定することができます。また、Performance Insights を使用してワークロードを視覚化することも可能です。

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

既に書き込み負荷が高いプロダクションクラスターでの書き込みアクティビティの急激な増加は、ライター DB インスタンスに過剰な負荷がかかる原因となり得ます。この急増によって課された負荷が、リーダーノードの遅延を引き起こす場合があります。これは、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 のストレージ層の間で一時的なネットワーク通信障害が発生する場合があります。リーダーノードは、ネットワークにおける短時間の中断により、遅れたり、再起動したりすることがあります。Aurora レプリカは、大量の変更、または AZ 間での短時間のパケット損失によってネットワークが飽和状態になることが原因で遅れる場合があります。この問題を回避するベストプラクティスは、DB インスタンスのサイズと、そのネットワーク機能を検討することです。

重要: バージョン 1.17.4 以降の Aurora MySQL 1.x には、把握しておく必要がある重要な機能がいくつかあります。

aurora_enable_replica_log_compression は、レプリケーションペイロードの圧縮を有効にして、プライマリレプリカと Aurora レプリカ間のネットワーク帯域幅の使用率を改善するクラスターパラメータです。これは、ネットワークが明らかに飽和状態である場合に役立ちます。
aurora_enable_zdr は、開いている接続を維持し、Aurora レプリカの再起動時にそれらを保持するために使用できるクラスターパラメータです。
aurora_enable_staggered_replica_restart は、Aurora レプリカが時間差の再起動スケジュールに従って、クラスターの可用性を高めることを可能にするクラスターパラメータです。