web-dev-qa-db-ja.com

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

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

先月、リモートセカンダリサーバーを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のエラーログとセカンダリサーバーのイベントビューアの両方を確認しましたが、異常なことはありませんでした。

sql-serveravailability-groupsupgradesql-server-2017distributed-availability-groups
22
Taryn

これは決定的な答えではありませんが、 Taryn とチャットした後の最良の答えです。

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

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

残念ながら問題が解決したため、それが何であったかを正確に述べることは困難です...しかし、将来的にこれが誰かに発生した場合：

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

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

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

8
Sean Gallardy

この前置きとして、本番環境には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 STARTUP SPIDは、やり直し操作を処理するものです）。ブロッキングSPIDを事前に確認して原因を特定し、特定することをお勧めします（通常は長時間実行されるレポート）。

これに関する詳細情報が必要な場合は、優れた記事（XEを使用したこの種の動作の監視を含む） here があります。

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についてもう少し詳しく説明しています。

4
Dan

分散可用性グループ（DAG）は異なるリージョン間で分割されていますか？その場合、デフォルトのSESSION_TIMEOUT値（10秒）が小さすぎることが原因と考えられます。これは、2つのリージョン間のレイテンシが高すぎて、同期を確実に完了できないことを意味します。

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

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

0
Nikos Kyriacou