動作については別途まとめようと思いますが、SQL Database で Geo レプリケーションを使用した場合の同期状況を確認する場合に、確認をしておきたい情報についてまとめておきたいと思います。
Geo レプリケーションについては、Always On 可用性グループの非同期レプリカが分散型可用性グループで使用されているはずですので、基本的な動作については、SQL Server の次の情報を把握する必要があります。
可用性グループのデータベース同期については、大きな要素としては次の 2 種類の同期状況を把握しておく必要があります。
- トランザクションログへの反映状況 (Log Sync / Hardening)
- データファイルへの反映状況 (Redo)
Always On 可用性グループの同期では、同期 / 非同期の設定については「トランザクションログへの反映状況」の動作に影響し、「データファイルへの反映状況」については、どちらの設定を使用しても、非同期で実行が行われます。
トランザクションログへの反映状況については geo レプリケーションのラグの監視 の情報を参考に、データファイルへの反映状況については、Troubleshooting REDO queue build-up (data latency issues) on AlwaysOn Readable Secondary Replicas using the WAIT_INFO Extended Event の情報を参考にすることで、詳細な情報や動作を把握することができるかと思います。
Geo レプリケーションの同期状況については、基本的に次の 3 種類の情報を組み合わせて確認を行うことができます。
- sys.dm_database_replica_states
- sys.dm_geo_replication_link_status
- sys.dm_os_performance_counters
- object_name が Database Replica / Availability Replica の項目を確認
同期の遅延が発生すると、セカンダリを使用した読み取りワークロードへの影響を考慮する必要が出てきます。読み取りワークロードへの影響については、読み取り専用レプリカを使用して読み取り専用クエリ ワークロードをオフロードする を確認するとよいかと。
トランザクションログへの反映状況の遅延 / データファイルへの反映状況の遅延については、SQL Database でも再現することができます。
トランザクションログへの反映状況の遅延については、BYOK を使用した透過的データ暗号化 (TDE) で使用することで、再現をさせることができます。
TDE の設定は、プライマリとセカンダリで個別に設定する必要があり、どちらの環境も同一の Key Vault のキーを使用する必要があります。
TDE 用のキーを格納している Key Vault のアクセスポリシーからセカンダリのアクセス許可を外し、アプリケーションの障害回復性のテスト のフェールオーバー用のコマンドを実行すれば、TDE の設定を復元することができず、セカンダリの DB をオフライン状況にすることで、トランザクションログの反映の遅延を再現させることができます。
データファイルへの反映状況の遅延については、Troubleshooting REDO queue build-up (data latency issues) on AlwaysOn Readable Secondary Replicas using the WAIT_INFO Extended Event の方法で再現することができます。
セカンダリで長時間アクセスされるクエリを実行している状態で、このクエリでアクセスしているテーブルに対して、プライマリで ALTER 等の SCH-M の取得が行われる操作を行うと、SCH-M のロック競合が発生し、これにより REDO スレッドによる REDO がブロッキングされるため、データファイルへの反映を遅延させることができます。
今回は同期で遅延が発生している場合に、どのような情報取得をできるかを検討するための情報取得が目的だったのですが、意図的に遅延を再現できると、ディザスター リカバリーの訓練の実行 のような DR 訓練を実施する場合にも役に立つのではないでしょうか。