状態を元に戻す可用性グループ データベースのトラブルシューティング

この記事は、状態を元に戻す可用性グループ データベースのトラブルシューティングに役立ちます。

状態を元に戻す方法

状態を元に戻すことは、プライマリと同期して戻すために、セカンダリ サーバーが既に適用した変更を元に戻す必要がある場合に発生します。

可用性グループのプライマリ レプリカとセカンダリ レプリカは、通常の操作中に接続状態のままであるため、プライマリ レプリカでの変更はセカンダリ レプリカとアクティブに同期されます。

フェールオーバー中、この接続状態は切断されます。 新しいプライマリ レプリカがオンラインになると、プライマリ レプリカとセカンダリ レプリカの間の接続が再確立されます。 この初期状態では、プライマリと同期するように新しいセカンダリが復旧を開始する必要がある一般的な復旧ポイントがネゴシエートされます。

フェールオーバー時に大規模なトランザクションが実行されている場合、新しいセカンダリ データベース ログはプライマリ レプリカ データベースの前にあります。 ネゴシエートされた新しい共通復旧ポイントでは、同期を再開できる状態にするために、セカンダリ レプリカがプライマリ レプリカからページを受信する必要があります。 元に戻すプロセスは、"やり直しの元に戻す" とも呼ばれます。

元に戻すプロセスは本質的に遅く、頻繁に発生し、通常は状態を元に戻す小さなトランザクションはほとんど認識されません。 状態を元に戻すと、フェールオーバーによって大きなトランザクションが中断され、多くのページがプライマリからセカンダリに送信され、セカンダリ レプリカ データベースが回復可能な状態に戻されることがよくあります。

状態を元に戻す可用性グループ データベースの症状と影響

データベースがセカンダリ レプリカの状態を元に戻している場合、データベースは同期されないため、プライマリ レプリカから変更を受け取りません。 プライマリ レプリカ上のデータベースが突然失われると、データが失われる可能性があります。

Always On ダッシュボード レポートがプライマリで同期していない

可用性グループをフェールオーバーした後、フェールオーバーが成功した間、セカンダリが同期していないと報告される場合があります。 Always On ダッシュボードでは、プライマリとセカンダリの Reverting の同期中が報告されます。

Always On ダッシュボード レポートがプライマリで同期していない	Always On ダッシュボード レポートのセカンダリでの元に戻す

Always On DMV レポートがプライマリで同期していない

プライマリ上の次の Always On 可用性グループ (AG) 動的管理ビュー (DMV) に対してクエリを実行すると、データベースは NOT SYNCHRONIZING 状態になります。

SELECT DISTINCT ar.replica_server_name, drcs.database_name, drs.database_id, drs.synchronization_state_desc, drs.database_state_desc
FROM sys.availability_replicas ar 
JOIN sys.dm_hadr_database_replica_states drs 
ON ar.replica_id=drs.replica_id 
JOIN sys.dm_hadr_database_replica_cluster_states drcs
ON drs.group_database_id=drcs.group_database_id

セカンダリ上の DMV に対してクエリを実行すると、可用性グループ データベースは REVERTING 状態になります。

読み取り専用ワークロードとレポート ワークロードがセカンダリ データベースにアクセスできない

セカンダリ データベースが元に戻されている間は、アクセスまたはクエリを実行できません。 これらの読み取り専用ワークロードはオフラインであり、中断されます。 データベースが状態を元に戻す期間によっては、これらのワークロードがビジネス クリティカルな場合は、それらのワークロードを別のセカンダリ レプリカまたはプライマリ レプリカに再ルーティングすることが必要になる場合があります。

セカンダリ レプリカにルーティングされるレポート ワークロードなど、読み取り専用ワークロードがある場合、これらのバッチはメッセージ 922 で失敗する可能性があります。

メッセージ 922、レベル 14、状態 1、2 行目のデータベース 'agdb' が復旧中です。 復旧が終了するまでお待ちください。

状態を元に戻すセカンダリ レプリカ データベースにログインしようとしているアプリケーションが接続に失敗し、エラー 18456 が発生します。

2023-01-26 13:01:13.100 ログオン エラー: 18456、重大度: 14、状態: 38。 2023-01-26 13:01:13.100 ユーザー '<UserName>' のログオン ログインに失敗しました。 理由: 明示的に指定されたデータベース 'agdb' を開けませんでした。 [CLIENT: <ローカル コンピューター>]

失敗したログインが監査されている場合は、SQL Server エラー ログでもこのエラーを報告できます。

元に戻す状態の残り時間を見積もる

次のいずれかの方法を使用して、元に戻す状態の残り時間を見積もります。

AlwaysOn_health XEvent セッションを使用する

AlwaysOn_health拡張イベント診断ログには、状態の進行状況を 5 分ごとに元に戻すhadr_trace_message イベントがあります。

SQL Server Management Studio (SSMS) オブジェクト エクスプローラーを使用してセカンダリ レプリカに接続し、Management、Extended Events、Sessions にドリルダウンします。 AlwaysOn_healthイベントを右クリックし、[ライブ データのウォッチ] 選択。 元に戻す操作の現在の状態を報告する新しいタブ付きウィンドウが表示されます。 状態は、 hadr_trace_message イベントを介して 5 分ごとに報告され、元に戻す操作の完了した割合が報告されます。

セカンダリ レプリカの SQL Server エラー ログは、元に戻す完了を推定するときにあまり役に立たない。 次の図から、 10:08 から 11:03 まで観察できます 状態を元に戻している間、ほとんど報告されません。 セカンダリがプライマリ レプリカからすべてのページを受信すると、元のプライマリで実行されていたトランザクションをロールバックして、状態を元に戻すことができるようになります。 復旧は、 11:03 から 11:05 まで実行。 復旧が完了するとすぐに、データベースはプライマリ レプリカとの同期を開始し、セカンダリ データベースが状態を元に戻している間にプライマリで行われたすべての変更に追いつきます。

パフォーマンス モニターを使用して完了時間を元に戻す監視

パフォーマンス カウンター SQL Server:Database Replica:Total Log Requiring Undo および SQL Server:Database Replica:Log Remaining for Undo を使用して状態の戻しの進行状況を監視し インスタンスの可用性グループ データベースを選択します。 次のスクリーンショットの例では、 Total Log Requiring Undo は 56.3 mb として報告され、 Log Remaining for Undo は 0 に徐々にドロップされ、進行状況を元に戻しています。

待機以外のオプションは何ですか?

Microsoft では、状態を元に戻す完了までの時間を見積もうことをお勧めします。

可用性グループへのセカンダリ レプリカの追加

可用性グループにレプリカが 2 つしかない場合は、可能であれば、高可用性と冗長性を提供し、他のセカンダリが元に戻す間にプライマリ レプリカとアクティブに同期できる別のセカンダリ レプリカを追加します。

失敗した読み取り専用ワークロードに対処する方法

元に戻すセカンダリ レプリカ データベースにアクセスできないので、読み取り専用ワークロードは失敗します。 影響を受けるセカンダリ レプリカ データベースの元に戻すプロセスが完了するまで、トラフィックをプライマリ レプリカまたは別のセカンダリ レプリカにルーティングするように、読み取りインテント ルーティング テーブルを更新します。

状態を元に戻さないようにする - 大規模なトランザクションを監視する

計画フェールオーバー中にこの状態を頻繁に監視する場合は、フェールオーバーの前に大規模なトランザクションをチェックするプロシージャを実装します。 次のクエリは、システム上の開いているトランザクションのトランザクションの開始時刻と現在の時刻を報告し、トランザクションの入力バッファーを提供します。

SELECT tat.transaction_begin_time, getdate() AS 'current time', es.program_name, es.login_time, es.session_id, tst.open_transaction_count, eib.event_info
FROM sys.dm_tran_active_transactions tat
JOIN sys.dm_tran_session_transactions tst ON tat.transaction_id=tst.transaction_id
JOIN sys.dm_exec_sessions es ON tst.session_id=es.session_id 
CROSS APPLY sys.dm_exec_input_buffer(es.session_id, NULL) eib WHERE es.is_user_process = 1
ORDER BY tat.transaction_begin_time ASC