web-dev-qa-db-ja.com

AlwaysOn AGセカンダリレプリカが高いREDOキューサイズと推定リカバリ時間と良好なREDOレートを持つ原因は何ですか？

SQL14はプライマリサーバー、SQL16はセカンダリレプリカであり、同期コミット可用性モードを使用してセットアップされます。

AlwaysOn AG Dashboard

昨日の時点で、プライマリからレプリカへのデータの同期が停止したようです。今朝、可用性データベースを一時停止してから再開しました。新しいデータが今送られてくるのを見ると、同期が再びキックするように見えましたが、ダッシュボードのRedo Queue SizeとEstimated Recovery Timeはまだ大きく、増え続けています。

これを修正するために、何を確認/実行できますか？

追加情報：サーバーバージョン：SQL Server 2016 Enterprise-SP1（プライマリとセカンダリの両方）

また、朝の早い段階で、長時間実行されているインデックスの再編成/再構築ジョブがプライマリで失敗しました。 （それは約4時間前でしたが、それでも今でもこの問題の原因である可能性がありますか？）

次のサーバーがセカンダリにログオンしていることに気付きました（古いものから新しいものへ）。 SQL Server Error Log 1

SQL Server Error Log 2

SQL Server Error Log 3

そこに手掛かりがあるかどうかわからない？

セカンダリのDBCC OPENTRANは次を返します： DBCC OPENTRAN on Secondary

セカンダリでの待機を追跡する拡張イベントセッション： Extended Events Session on Secondary

sql-serverreplicationsql-server-2016availability-groupsdata-synchronization
2
J.D.

だからここにいくつかのこと...（これは長い答えになるでしょう、そして何度も繰り返されるかもしれません）：

まずそして何よりもこのAGはフェイルオーバーを経験しましたか？そうでない場合は、プライマリノードのERRORLOGをチェックして、トラブルシューティングプロセスを開始することをお勧めします。フェイルオーバーが発生した場合は、ノードのERRORLOGsを確認して、正式にはPrimary と呼ばれ、何が起こったかを確認します。 SSMS内の不格好なUIを使用することも、文書化されていない拡張プロシージャ xp_readerrorlog を使用することもできます。これは、この方法でノイズを除去する方が速いので、私の推奨です。たとえば、次のようなAG名への参照を探し始め、そこから掘り下げることをお勧めします。

xp_readerrorlog 0, 1, N'>>YOUR AG NAME HERE<<', NULL, '2019-11-18 12:00:00.000', '2019-11-19 15:00:00.000', NULL, NULL

コマンドを囲む構文については、上記のリンクを確認してください。

見つかった情報に基づいて、Windowsイベントログ（eventvwr.msc）、クラスターログ（cluadmin.msc）、アプリケーションログなどをチェックする検索を展開します。必要に応じて、エラー時間を参照ポイントとして使用します。これらのログは、クラスター関連の問題、メンテナンスによる問題など、同期が停止した原因を特定すると思われます。これに基づいて、結果の解釈に問題がある場合は、新しい質問を投稿することをお勧めします。

2番目に、AGでインデックスメンテナンスを実行すると、AG同期遅延が発生します。 SQL Serverのバージョン（SQL 2019を含む）に関係なく、回避策はありませんが、新しいバージョンの方が早く回復する傾向があります。インデックスメンテナンスを実行する必要があり、アプリケーションをオフラインにできる場合は、オフラインでインデックスメンテナンスを実行することをお勧めします。オフラインでのREBUILDsをMAXDOPを定義して実行します。オフラインインデックスの再構築操作では、AG内でそれほど深刻な遅延が発生しないためです。このアプローチは明らかに停止を引き起こすので、簡単に行うことはできません。私はこれを行う環境をサポートしています。インデックスのメンテナンスを怠ると不必要な成長が発生するためです（他の問題を引き起こすマルチTBシステムでは））

簡単に言えば、SQL Serverコミュニティでよくある誤解は、インデックスのメンテナンスはデータベースのパフォーマンスにとって非常に重要であるということです。インデックスの断片化には 実行プランの動作への影響が最小限 しかないため、これは一般的には当てはまりません。ページあたりの平均余白が悪質なレベルに近づいた場合にのみ、 断片化が問題になり始めます 。正直なところ、ほとんどの場合、インデックスのメンテナンスは基本的に非常に費用のかかる統計更新操作です。つまり、統計の更新の上にあり、通常はブロックを引き起こさず、またAGをバックアップしないでください。

最後に、セカンダリがどれだけ遅れているかを確認し、セカンダリが追いつくまでにかかる時間の見積もりを取得するには、このクエリに Jonathan Kehayiasからのこのコード のバリアントであるものを試してください。

SELECT ar.replica_server_name, 
       adc.database_name, 
       ag.name AS ag_name, 
       drs.is_local, 
       drs.synchronization_state_desc, 
       drs.synchronization_health_desc, 
       drs.last_redone_time, 
       drs.redo_queue_size, 
       drs.redo_rate, 
       (drs.redo_queue_size / drs.redo_rate) / 60.0 AS est_redo_completion_time_min,
       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;
4
John Eisbrener