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

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

状態を元に戻す方法

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

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

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

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

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

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

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

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

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

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) オブジェクト エクスプローラーを使用してセカンダリ レプリカに接続し、管理、拡張イベント、セッションにドリルダウンします。 AlwaysOn_health イベントを右クリックし、[ライブ データの監視] を選択します。 元に戻す操作の現在の状態を報告する新しいタブ付きウィンドウが表示されます。 状態はイベントを介して hadr_trace_message 5 分ごとに報告され、元に戻す操作の完了率が報告されます。

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

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

パフォーマンス カウンター SQL Server:D atabase Replica:Total Log Requiring Undo と SQL Server:D atabase Replica:Log Remaining for Undo を使用して状態の元に戻す進行状況を監視し、インスタンスの可用性グループ データベースを選択します。 次のスクリーンショットの例では、 元に戻す必要があるログの合計 は 56.3 mb と報告され、 元に戻すログの残り は、進行状況を元に戻す レポートの 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