サーバーの再起動後にSQL Server分散可用性グループデータベースが同期しない

SQL Serverで大規模なアップグレードを実行する準備ができており、先に進む前に解決しようとしている分散可用性グループの異常な動作に気付いています。

先月、リモートセカンダリサーバーをSQL Server 2016からSQL Server 2017にアップグレードしました。このサーバーは、複数の分散可用性グループ（DAG）と個別の可用性グループ（AG）の一部です。このサーバーをアップグレードしたときに、サーバーが読み取り不能な状態になることを認識していなかったため、この1か月間はプライマリサーバーのみに依存していました。

今後のアップグレードの一環として、CU 4パッチをサーバーに適用し、再起動しました。サーバーがオンラインに戻ったとき、パッチを適用したばかりのセカンダリは、すべてのDAG / AGが問題なく同期していることを示しました。

ただし、プライマリーは非常に異なるストーリーを示していました。報告していた

• 別のAGが問題なく同期していた
• しかし、DAGは非同期/非正常状態でした

最初にパニックに陥った後、次のことを試みて、DAGで再び同期を取りました。

• プライマリから、データの移動を停止して再開しました。これはデータの同期を開始しませんでした。
• セカンダリ（パッチを適用したばかりの）ALTER DATABASE [<database] SET HADR RESUME;で実行しました-エラーなしで実行されますが、同期は再開されませんでした

データを再び同期する最後の試みは、セカンダリにログインし、SQL Serverサービスを手動で再起動することでした。サービスを手動で再起動するのは少し極端に思えます。サーバーを再起動すれば十分だったと思うからです。

再起動後にDAGがセカンダリへの同期を開始しないという問題に誰かが遭遇しましたか？もしそうなら、それはどのように解決されましたか？

SQL Serverのエラーログとセカンダリサーバーのイベントビューアーの両方を確認しましたが、目に見える異常はありませんでした。

これは決定的な答えではありませんが、Tarynとチャットした後の最良の答えであることに注意してください。

ただし、プライマリーは非常に異なるストーリーを示していました。別のAGが問題なく同期しているが、DAGが同期していない/正常ではない状態であると報告されていました

分散AGの基になっている個々のデータベースとAGが正常で同期していると言う場合、これはDMVやSSMSダッシュボードの問題である可能性が高いです。エラーログにはレプリカが接続されなかったか、切断された状態であることを示唆するものは何もなかったためです。

残念ながら、この問題は解決されたため、それが何であったかを正確に言うのは難しいですが、将来これが誰かに発生した場合：

• すべてのクラスターでsys.dm_hadr_database_replica_statesをチェックして、正常でないものを探します。すべてが正常に表示される場合、DMVがまだ更新されていない可能性があります
• 正常でない場合は、エラーログ/ DMVで接続の問題を確認します（フォワーダー/グローバルプライマリに接続できないなど）
• ダンの答えは、データベースの起動から発生する可能性のある問題に言及しています-ただし、この場合、インスタンスを読み取ることができないため、ほとんどの場合は問題ではなく、あなたのケースになる可能性があります
• データベースが読み取り可能な場合、ダミーのテーブル/挿入または...
• DEBUGチャネルアイテムを使用する拡張イベントセッション、sqlserver.hadr_dump_log_blockまたはsqlserver.hadr_apply_log_blockセカンダリが実際にログブロックを受信/適用しているかどうかを確認する...
• Perfmonオブジェクト SQLServer:Database Replica\Log Bytes Received/sec

そのセカンダリでデータを受信して​​いるが、分散agがまだ同期していないか正常ではない場合は、ログブロックを受信して​​処理しているため、DMV値が変化するかどうかを少し見てみましょう。

ただし、そうでない場合は、さらに調査する必要がありますが、答えの範囲外です。

これには、本番環境ではDAGがまったくないという警告を前書きします。基本的に、このアドバイスはAGとDAGの両方に適用されるべきです。

サービスの再起動後に同期が再開されましたか？その場合、原因に対する私の最善の推測は、REDO SPIDのブロックです。再起動してもまだ同期しない場合は、次のことを最初に確認します。

AG REDO SPIDのブロック

通常、読み取り可能なセカンダリでのみ発生します。確認するには、次を実行します。

select session_id, blocking_session_id, db_name(database_id), wait_type
from sys.dm_exec_requests
where command = 'DB STARTUP'

ブロッキングSPIDが表示された場合、セカンダリを再開する前にそれらを強制終了する必要があります（DB STARTUPSPIDはREDO操作を処理します）。ブロッキングSPIDを事前に確認して、原因（通常は長時間実行されるレポート）を判別することをお勧めします。

これに関する詳細情報が必要な場合は、素晴らしい記事（XEを使用したこのタイプの動作の監視を含む）を参照してください。

DMVを確認する

データの移動が中断された場合、DMVを参照して中断理由に関する詳細を取得できます。以下を実行します。

select db_name(database_id), synchronization_state_desc, database_state_desc, suspend_reason_desc
from sys.dm_hadr_database_replica_states

BOLの記事はもう少しsuspend_reasonを説明しています。

分散可用性グループ（DAG）は異なる地域間で分割されていますか？その場合、デフォルトのSESSION_TIMEOUT値（10秒）が低すぎることに悩まされる可能性があります。これは、2つの領域間の遅延が高すぎて、確実に同期を完了できないことを意味します。

通常の可用性グループでは、SESSION_TIMEOUT値を増やして、同期セッションをより安定させることができます。昨年末、DAGのSESSION_TIMEOUTパラメーターを編集できないことに気付きました。これは、DAGは低遅延シナリオでのみ実行可能であることを意味していました。Microsoftにチケットを記録し、今年の初めにホットフィックスがリリースされました。

改善：SQL Server 2016および2017の分散可用性グループレプリカのSESSION_TIMEOUT値を構成する