可用性グループのレプリカ同期の監視

SQL Server可用性グループを展開する場合、展開を成功させるための重要な側面の1つは、セカンダリレプリカデータベースとプライマリレプリカの同期を監視することです。可用性グループでレプリカの同期を監視する方法は複数あります。この投稿では、それぞれの方法を示し、それぞれの長所と短所について説明します。

可用性グループ、各レプリカサーバー、および可用性データベースのステータスを監視する最も簡単な方法の1つは、ManagementStudioの組み込みダッシュボードを使用することです。ただし、ダッシュボードのデフォルトレイアウトでは詳細があまり提供されないため、レプリカサーバーと可用性データベースに関する追加情報を表示するようにカスタマイズする必要があります。以下に示すように、ダッシュボードの[列の追加と削除]リンクを使用するか、既存の列ヘッダーのいずれかの右クリックコンテキストメニューを使用して、追加の列をレイアウトに追加できます。

SSMSでのAGダッシュボードのカスタマイズ

可用性データベースの場合、ログ送信キューサイズ（KB）、ログ送信レート（KB /秒）、推定データ損失（時間）、推定回復時間（秒）、および同期パフォーマンス（秒）を監視すると、理解が深まります。データがレプリカにどのように流れているか、および可用性データベースの全体的な状態について説明します。たとえば、以下のスクリーンショットでは、SQL03のVMネットワーク構成を変更して、待ち時間が長くなり、スループットが低くなるようにしました。これは、データベースの同期に影響を及ぼします。

ここでは、SQL03の潜在的なデータ損失が約6分あり、セカンダリ（この場合は非同期セカンダリ）に7MB/秒の速度で送信されている505MBの未送信ログがあることがわかります。 。 SQL02は現在追いついており、構成の同期セカンダリとしてデータが失われることはありません。

可用性グループダッシュボードの代わりに、ダッシュボードがソースとして情報を取得するDMVの直接クエリがあります。次のクエリは、可用性グループ内の各データベースの現在のステータスと同期メトリックを示しています。

SELECT 
	ar.replica_server_name, 
	adc.database_name, 
	ag.name AS ag_name, 
	drs.is_local, 
	drs.is_primary_replica, 
	drs.synchronization_state_desc, 
	drs.is_commit_participant, 
	drs.synchronization_health_desc, 
	drs.recovery_lsn, 
	drs.truncation_lsn, 
	drs.last_sent_lsn, 
	drs.last_sent_time, 
	drs.last_received_lsn, 
	drs.last_received_time, 
	drs.last_hardened_lsn, 
	drs.last_hardened_time, 
	drs.last_redone_lsn, 
	drs.last_redone_time, 
	drs.log_send_queue_size, 
	drs.log_send_rate, 
	drs.redo_queue_size, 
	drs.redo_rate, 
	drs.filestream_send_rate, 
	drs.end_of_log_lsn, 
	drs.last_commit_lsn, 
	drs.last_commit_time
FROM sys.dm_hadr_database_replica_states AS drs
INNER JOIN sys.availability_databases_cluster AS adc 
	ON drs.group_id = adc.group_id AND 
	drs.group_database_id = adc.group_database_id
INNER JOIN sys.availability_groups AS ag
	ON ag.group_id = drs.group_id
INNER JOIN sys.availability_replicas AS ar 
	ON drs.group_id = ar.group_id AND 
	drs.replica_id = ar.replica_id
ORDER BY 
	ag.name, 
	ar.replica_server_name, 
	adc.database_name;

プライマリレプリカでDMVに直接クエリを実行することにより、ManagementStudioのダッシュボードの更新期間を待たずに最新の情報を簡単に取得できます。これは、データセンター間のリンク障害が発生したクライアントや、一定期間メンテナンスのために接続がダウンしていて、接続が復元された後、セカンダリレプリカが追いつく過程にあるクライアントと相談するときに、数回役立ちました。 。

可用性グループの同期を監視するための最後のネイティブツールは、SQLServer：DatabaseReplicaパフォーマンスオブジェクトを使用するパフォーマンスモニターです。次の表は、Books Online（https://msdn.microsoft.com/en-us/library/ff878356(v=sql.110).aspx）の関連するパフォーマンスカウンターとその説明を示しています。

パフォーマンスモニターを使用して環境を監視する際の課題と制限の1つは、オブジェクトがセカンダリレプリカをホストするSQLServerのインスタンスでのみ有効であることです。つまり、各セカンダリレプリカのカウンターをパフォーマンスモニターに追加して、すべてのセカンダリデータベースで何が起こっているかを完全に把握する必要があります。ここで、ManagementStudioのAGダッシュボードとプライマリレプリカに対するDMVクエリの両方が提供されます。 1つの場所にあるすべてのセカンダリデータベースに関する情報。

可用性グループの同期を監視するための組み込み機能の代わりに、標準機能として可用性グループの監視を含むSQL SentryPerformanceAdvisorなどのサードパーティツールを活用することもできます。この機能の詳細については、製品のバージョン7.5でこの機能を最初に導入したGregGonzalezのブログ投稿を参照してください。

PerformacnceAdvisorAGダッシュボード

Performance Advisorの[レプリカ]タブを使用すると、各セカンダリレプリカサーバーを拡張して、データベースとその現在の同期データを簡単に表示できます。ダッシュボードの上部にあるWSFCノード/グループマトリックスのデフォルトレイアウトには、プライマリレプリカの送信キューステータス、セカンダリレプリカのREDOキューステータス、および各レプリカサーバー間のデータフローに関するヘルス情報も表示されます。この例では、SQL01とSQL03の間の接続の問題が修正された後、プライマリのログ送信キューが現在、サーバー間の線の幅に基づいて、SQL01からSQL03に大量のデータを送信していることがわかります。環境。右側のグラフは、SQL01からデータが転送される速度と、ログ送信キューの現在のサイズを示しています。これは、左側で選択されているレプリカであるためです。 WSFCノード/グループマトリックスレイアウトで他のレプリカサーバーの1つをクリックすると、右側の特定のレプリカのパフォーマンスメトリックに一致するようにグラフも変更されます。

SQLServerの可用性グループ内のレプリカサーバー間のデータ同期のパフォーマンスを監視する方法は多数あります。 Management Studioに組み込まれている可用性グループダッシュボードには、ダッシュボードに最も重要な情報を表示するようにレイアウトをカスタマイズする方法がわかれば、簡単にアクセスできる豊富な情報が含まれています。プライマリレプリカサーバーから直接DMVを使用して、Transact-SQLを使用したデータ同期のパフォーマンスを監視することもできます。また、SQL Sentryなどのサードパーティツールには、データ同期の監視も含まれています。パフォーマンスモニターはこれと同じ情報を提供できますが、パフォーマンスカウンターはセカンダリレプリカサーバーからのみ利用できるため、環境全体の全体像を把握するのに少し手間がかかります。