RDS for SQL Server リードレプリカの遅延をトラブルシューティングするにはどうすればよいですか?

簡単な説明

Amazon RDS for SQL Server エンタープライズエディションでは、同じリージョン内でのリードレプリカの作成がサポートされています。データレプリケーションは非同期で、Always-On テクノロジーを使用してマスターインスタンスからレプリカインスタンスにデータをレプリケートします。RDS for SQL Server は、ソース DB インスタンスとそのリードレプリカの間の高いレプリカの遅延を緩和するために介入しません。

解決方法

1.    Amazon CloudWatch を使用して、マスターインスタンスとレプリカインスタンスのリソース使用状況を確認します。Enhanced Monitoring 機能と Performance Insights 機能を使用して、リソースの使用状況をきめ細かくチェックします。

マスターインスタンスとレプリカインスタンスのメトリクスに関する重要な考慮事項:

• CPU の使用状況がスロットリングされていないことを確認してください。バースタブルインスタンスクラスを実行している場合は、CPU クレジットが使用可能であること、または [Unlimited] (無制限) モードで実行していることを確認してください。
• FreeableMemory が十分にあることを確認してください。また、ReadIOPS と WriteIOPS がプロビジョニングされた制限に達していることを確認してください。GP2 ボリュームを使用している場合は、十分なバーストバランスが取れていることを確認してください。詳細については、「RDS for SQL Server インスタンスの空きメモリ不足のトラブルシューティング方法を教えてください」を参照してください。
• ReadThroughput と WriteThroughput がインスタンスクラスの制限に達していないことを確認してください。

2.    同じインスタンスクラス、ストレージタイプ、IOPS 数でマスターインスタンスとレプリカインスタンスを作成するのがベストプラクティスです。これにより、レプリカインスタンスのリソース不足によるレプリカの遅延を回避できます。さらに、ワークロードに応じて、マスターインスタンスに比べて使用量が極めて少ない場合は、リードレプリカをスケールアップまたはスケールダウンできます。

3.    レプリカの遅延が増加し始めた時期を特定し、次の操作を実行します。

レプリカの遅延の開始時刻に基づいて、マスターインスタンスの WriteIOPS、WriteThroughput、NetworkReceiveThroughput、NetworkTrasmitThroughput の各メトリクスを確認します。遅延が書き込みアクティビティによるものかどうかを確認します。リードレプリカで同じ時間帯の同じメトリクスを確認します。

マスターインスタンスに実行時間の長いトランザクションがあるかどうかを確認します。アクティブなトランザクションのステータスをチェックするクエリの例を次に示します。

SELECT * FROM sys.sysprocesses WHERE open_tran = 1;

4.    レプリカインスタンスで、重大なロック待機やデッドロックが発生していないかどうかを確認します。Select と DDL/DML のトランザクション間でデッドロックが発生し、マスターインスタンスからのトランザクションログの適用に遅延が生じます。

ブロックされているかどうかをチェックするクエリの例を次に示します。

SELECT * FROM sys.sysprocesses WHERE blocked > 0;

5.    レプリカの遅延とレプリカの最大遅延をチェックするクエリ。

レプリカのラグ

SELECT AR.replica_server_name
     , DB_NAME (ARS.database_id) 'database_name'
     , AR.availability_mode_desc
     , ARS.synchronization_health_desc
     , ARS.last_hardened_lsn
     , ARS.last_redone_lsn
     , ARS.secondary_lag_seconds
FROM sys.dm_hadr_database_replica_states ARS
INNER JOIN sys.availability_replicas AR ON ARS.replica_id = AR.replica_id
--WHERE DB_NAME(ARS.database_id) = 'database_name'
ORDER BY AR.replica_server_name;

リードレプリカで「last_hardened_lsn」の値が進行中であることを確認します。

レプリカの最大ラグ

SQL Server の場合、ReplicaLag メトリクスは、遅延が発生したデータベースの最大遅延を秒単位で示します。例えば、2 つのデータベースがそれぞれ 5 秒と 10 秒遅延している場合、ReplicaLag は 10 秒となります。ReplicaLag メトリクスは、次のクエリの値を返します。マスターインスタンスでクエリを実行します。

select max(secondary_lag_seconds) max_lag  from sys.dm_hadr_database_replica_states;

6.    リードレプリカの作成を開始すると、マスターインスタンスからスナップショットが取得され、その後に復元されてリードレプリカインスタンスが作成されます。トランザクションログは再生され、データがマスターインスタンスと同期されます。ただし、新しいインスタンスを作成すると、そのインスタンスで遅延読み込みが発生し、レプリカの遅延が発生します。これは想定される動作です。遅延読み込みの影響を最小限に抑えるには、リードレプリカの作成時に IO1 タイプのストレージを使用し、必要に応じてそれを GP2 に変換し直します。

7.    マスターインスタンスでトランザクションをバッチで実行します。これにより、長いトランザクションの実行が回避され、トランザクションログファイルのサイズが最小限に抑えられます。レプリカの遅延が大きいときに必要な場合以外は、レプリカインスタンスを再起動しないでください。再起動すると、トランザクションログの再生がさらに遅くなります。

8.    マスターインスタンスまたはレプリカインスタンスのインスタンスクラスを変更すると、一時的にレプリカの遅延が発生する可能性があります。ログはマスターインスタンスから処理するため、これは想定どおりの動作です。

ストレージタイプまたはストレージサイズを変更すると、ストレージの最適化が完了するまでのレプリカの遅延への影響が長引きます。RDS インスタンスでストレージ最適化がどの程度 (%) 完了しているかはわかりません。

9.    リードレプリカがストレージフルの状態に達すると、マスターインスタンスからのトランザクションログは処理されず、レプリカの遅延が大きくなります。

ストレージスペースが TempDB または一時テーブルに起因していることが考えられる場合は、レプリカインスタンスを再起動してスペースを一時的に解放します。

10.    レプリカの遅延のステータスが改善されない場合は、レプリカインスタンス上のユーザーデータベースのステータスを確認します。ログを再生するには、データベースのステータスが [Online] (オンライン) である必要があります。

次の点に注意してください。

• 新しく作成されたデータベースは、リードレプリカでアクセス可能になるまで遅延の計算に含まれません。
• ReplicaLag は、レプリカの設定中など、RDS が遅延を特定できない場合、またはリードレプリカがエラー状態にある場合に -1 を返します。

---

関連情報

Amazon RDS での Microsoft SQL Server 用のリードレプリカの使用