Amazon RDS for SQL Server のリードレプリカにおける遅延をトラブルシューティングする方法を教えてください。

簡単な説明

Amazon RDS for SQL Server Enterprise エディションは、同じ AWS リージョンおよび、複数にわたるリージョンでのリードレプリカの作成をサポートしています。データ複製は非同期で行われ、常時稼働テクノロジーを使用してプライマリインスタンスからレプリカインスタンスにデータを複製します。RDS for SQL Server では、ソース DB インスタンスとそのリードレプリカ間で複製の遅延が大きくなった場合、自動的には軽減されません。

解決策

リソース使用率を確認する

Amazon CloudWatch 拡張モニタリングまたは Performance Insights を使用することで、詳細レベルでプライマリインスタンスおよびレプリカインスタンスのリソース使用状況を確認できます。

CPU 使用率がスロットリングされていないことを確認します。バースト可能なインスタンスタイプを使用する場合は、使用可能な CPU クレジットがあるか、Unlimitedモードが有効である必要があります。

FreeableMemory が十分であり、ReadIOPS および WriteIOPS がプロビジョニングされたクォータの条件を満たしていることを確認してください。gp2 ボリュームを使用している場合は、使用可能なバースト残高があることを確認してください。

ReadThroughput および WriteThroughput がインスタンスタイプのクォータに達しているかどうかを確認します。

注: レプリカインスタンス内のリソースが不足すると、レプリカラグが発生する可能性があります。プライマリインスタンスとレプリカインスタンスは、同じインスタンスタイプ、ストレージタイプ、IOPS 数で作成することがベストプラクティスです。使用量がプライマリインスタンスと比較して極めて少ない場合は、リードレプリカをスケールアップまたはスケールダウンすることもできます。

レプリカラグが増加し始めた期間を特定し、次のアクションを実行します。

• プライマリインスタンスの WriteIOPS、WriteThroughput、NetworkReceiveThroughput、NetworkTrasmitThroughput メトリクスを確認します。書き込みアクティビティが原因で遅延が発生しているかどうかを判断します。次にリードレプリカで、同じ期間の同じメトリクスを確認します。
• プライマリインスタンスに長時間実行されているトランザクションがあるかどうかを確認します。アクティブなトランザクションのステータスを確認するには、次の例のようなクエリを実行します。

  SELECT *
  FROM sys.sysprocesses
  WHERE open_tran = 1;

待機とデッドロックを特定する

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

ブロックをチェックするには、次の例のようなクエリを実行します。

SELECT * FROM sys.sysprocesses WHERE blocked > 0;

レプリカラグを確認する

プライマリインスタンスでクエリを実行し、レプリカラグと最大レプリカラグを確認します。

レプリカラグ

次のクエリを実行します。

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;

注: database_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;

データ同期とインスタンスの正常性を管理する

リードレプリカの作成時に、Amazon RDS はプライマリインスタンスからスナップショットを作成し、そのスナップショットを復元してリードレプリカインスタンスを作成します。Amazon RDS はトランザクションログを再現することで、データをプライマリインスタンスと同期します。ただし、新しいインスタンスの作成後にはインスタンスに遅延読み込みが発生し、レプリカラグにつながります。これは想定動作です。遅延読み込みの影響を軽減するには、リードレプリカを作成するときに io1 または io2 のボリュームタイプを使用します。レプリカを作成した後は、ボリュームタイプを gp2 または gp3 に戻すことができます。

プライマリインスタンスでトランザクションを一括実行すると、トランザクションが長くなるのを防ぎ、トランザクションログファイルのサイズを削減することができます。レプリカの遅延が大きい場合のみ、レプリカインスタンスを再起動してください。再起動しない場合、Amazon RDS がトランザクションログを再現するのが遅くなり、データベースが Recovery 状態になる可能性があります。

ログはプライマリインスタンスから処理されるため、プライマリインスタンスまたはレプリカインスタンスでインスタンスタイプを変更すると、一時的にレプリカラグが発生する場合があります。

ストレージタイプまたはストレージサイズを変更した場合も、ストレージの最適化が完了するまで一時的にレプリカラグが発生することがあります。ストレージ最適化の進行状況を監視することはできません。

レプリカラグが解消されない場合は、レプリカインスタンスでユーザーデータベースのステータスを確認します。ログを再現するには、データベースのステータスが Online である必要があります。

注:

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

関連情報

Amazon RDS で Microsoft SQL Server 用リードレプリカを使用する