500データベースのSQL Server 2017-CU9以降頻繁にAGが切断する

15

みなさん、こんにちは。あなたの助けに感謝します。SQL Server 2017可用性グループで課題が発生しています。

バックグラウンド

会社は小売B2Bバックエンドソフトウェアです。約500の単一テナントデータベース、およびすべてのテナントで使用される5つの共有データベース。ワークロードの特性は主に読み取られ、データベースの大部分のアクティビティは非常に低くなっています。

コロケーションでホストされている物理的な運用サーバーは、共有SAN / FCI構成のWindows Server 2012上のSQL Server 2014 Enterpriseから、2ソケット/ 32コア/ 768 GB RAMおよびローカルのWindows Server 2016上のSQL Server 2017 Enterpriseに最近アップグレードされましたAlwaysOn AGを使用したSSDドライブ。AGトラフィックは、クロスケーブル接続で専用の10G NICポートを使用します。

それらの要件は、すべてのデータベースが一緒にフェールオーバーすることであるため、すべてを単一のAGに配置する必要がありました。これは、同一サーバー上の単一の読み取り不可能な同期レプリカです。

新しいサーバーは、2018年6月から運用されています。最新のCU（当時のCU7）とWindowsの更新プログラムがインストールされ、システムは正常に機能していました。約1か月後、サーバーをCU7からCU9に更新した後、サーバーは優先度の高い順に以下の課題に気付き始めました。

SQL Sentryを使用してサーバーを監視しており、物理的なボトルネックは観察されていません。すべての重要な指標は良いようです。CPUは平均20％、IO時間は通常1ミリ秒未満、RAMは完全に使用されておらず、ネットワークは1％未満です。

課題

フェールオーバー後に症状は良くなるようですが、どちらのサーバーがプライマリであるかに関係なく、数日以内に戻ってきます。症状は両方のサーバーで同じです。

  1. 次のような散発的なクライアントタイムアウトと接続障害

    ...接続の確立中にエラーが発生しました...

    または

    実行タイムアウトが切れました

    場合によっては、これらは最大40秒間続き、その後沈静化します。

  2. トランザクションログバックアップジョブの完了には、以前よりも10倍時間がかかります。以前は、500個すべてのデータベースのログをバックアップするのに2〜3分かかりましたが、現在では15〜25分かかります。バックアップ自体が良好なスループットで正常に実行されることを確認しました。ただし、1つのログのバックアップが完了してから次のログを開始するまでにわずかな遅延があります。非常に低い値から始まりますが、1〜2日で2〜3秒かかります。500個のデータベースを乗算すると、違いがあります。

  3. 時々、ランダムに見える一部のデータベースが、手動フェールオーバー後に「同期していない」状態のままになります。これを解決する唯一の方法は、セカンダリレプリカでSQL Serverサービスを再起動するか、これらのデータベースを削除してAGに再結合することです。

  4. CU10で導入された別の問題（CU11では解決されていません）：master.sys.databasesでのブロッキングのセカンダリタイムアウトへの接続、およびセカンダリレプリカにSSMSオブジェクトエクスプローラーを使用することさえできません。根本的な原因は、Microsoft SQL Server VSSライターが次のクエリを発行してブロックしているようです。

    select name, 
       recovery_model_desc, 
       state_desc, 
       CONVERT(integer, is_in_standby), 
       ISNULL(source_database_id,0) 
  from master.sys.databases

観察

エラーログで喫煙銃を見つけたと思います。エラーログには、「情報のみ」としてラベル付けされたAGメッセージがいっぱいですが、まったく正常ではないように見え、その頻度とアプリケーションエラーとの非常に強い相関関係があります。

エラーにはいくつかの種類があり、順番に発生します。

  • DbMgrPartnerCommitPolicy :: SetSyncState：GUID

  • DbMgrPartnerCommitPolicy :: SetSyncAndRecoveryPoint：GUID

  • セカンダリデータベースとのAlwaysOn可用性グループ接続は、レプリカID {GUID}の可用性レプリカ 'DB'上のプライマリデータベース 'XYZ'に対して終了しました。これは情報メッセージです。ユーザーの操作は必要ありません。

  • レプリカID {GUID}の可用性レプリカ「DB」上のプライマリデータベース「ABC」に対して確立されたセカンダリデータベースとのAlwaysOn可用性グループ接続。これは情報メッセージです。ユーザーの操作は必要ありません。

数日のうちに数万人がいます。

この記事では、SQL 2016での同じ種類のエラーシーケンスについて説明しますが、そこでは異常と言います。これは、フェールオーバー後の「非同期」現象も説明しています。議論された問題は2016年のもので、今年初めにCUで修正されました。ただし、AGが既に確立されているため、自動初期シードメッセージへの参照以外の最初の2種類のメッセージについては、これが唯一の関連する参照です。

以下は、PRIMARYでタイプごとに1万個を超えるエラーが発生した日に対する、先週の日次エラーの要約です（セカンダリは「プライマリとの接続が失われています...」を示します）。

Date        Message Type (First 50 characters)                  Num Errors
10/8/2018   DbMgrPartnerCommitPolicy::SetSyncAndRecoveryPoint:  61953
10/3/2018   DbMgrPartnerCommitPolicy::SetSyncAndRecoveryPoint:  56812
10/4/2018   DbMgrPartnerCommitPolicy::SetSyncAndRecoveryPoint:  27951
10/2/2018   DbMgrPartnerCommitPolicy::SetSyncAndRecoveryPoint:  24158
10/7/2018   DbMgrPartnerCommitPolicy::SetSyncAndRecoveryPoint:  14904
10/8/2018   Always On Availability Groups connection with seco  13301
10/3/2018   DbMgrPartnerCommitPolicy::SetSyncState: 783CAF81-4  11057
10/3/2018   Always On Availability Groups connection with seco  10080

また、次のような「奇妙な」メッセージがときどき表示されます。

ミラーリングセッションまたは可用性グループが役割の同期のためにフェールオーバーしたため、可用性グループデータベース「DB」は役割を「SECONDARY」から「SECONDARY」に変更しています。これは情報メッセージです。ユーザーの操作は必要ありません。

...「SECONDARY」から「RESOLVING」に状態を変更するホストの中で。

手動フェールオーバーの後、システムはこれらのタイプの単一のメッセージなしで数日間移動する場合があり、突然、明らかな理由もなく、一度に数千を取得し、サーバーが応答しなくなり、アプリケーションが発生します接続タイムアウト。一部のアプリケーションには再試行メカニズムが組み込まれていないため、データが失われる可能性があるため、これは重大なバグです。このようなエラーのバーストが発生すると、次の待機タイプが急上昇します。これは、AGがすべてのデータベースへの接続を一度に失ったように見える直後の待機を示しています。

AGエラーの重大なバーストが発生したときに待機します

約30秒後、待機の点ではすべてが通常に戻りますが、AGメッセージは、さまざまなレートで1日のさまざまな時間、オフピーク時間を含むランダムな時間にエラーログをフラッディングし続けます。これらのエラーバースト中にワークロードが同時に増加すると、当然事態は悪化します。少数のデータベースのみが切断された場合、それ自体で十分に迅速に解決されるため、通常は接続がタイムアウトすることはありません。

問題が発生したのは実際にCU9であることを確認しようとしましたが、両方のノードをCU9にのみダウングレードできました。いずれかのノードをCU8にダウングレードしようとすると、そのノードはログに同じエラーを示す「解決中」状態のままになります。

対応するリソースID '…を持つAlways On可用性グループの永続的な構成を読み取ることができません。永続的な構成は、プライマリ可用性レプリカをホストする上位バージョンのSQL Serverによって書き込まれます。ローカルSQL Serverインスタンスをアップグレードして、ローカル可用性レプリカがセカンダリレプリカになるようにします。

つまり、両方のノードを同時にCU8にダウングレードするには、ダウンタイムを導入する必要があります。これはまた、AGのメジャーアップデートがあり、私たちが経験していることを説明できるかもしれないことを示唆しています。

すでにmax_worker_threadsをデフォルトの0（この記事に基づくボックスでは960 ）から徐々に最大2,000まで調整しようとしましたが、エラーへの影響は確認されていません。

これらのAG切断を解決するために何ができますか？そこに誰かが同様の問題を経験していますか？AGに多数のデータベースを持つ他の人は、おそらくCU9またはCU8で始まるSQLエラーログに同様のメッセージを見ることができますか？

助けてくれてありがとう！

sql-server  availability-groups  sql-server-2017 
— SQLRaptor
ソース

回答:

9

更新：

  1. 頻繁な可用性グループの切断は、CU9によって導入されたリグレッションであることが確認され、CU12のインストール後に解決されました。

  2. セカンダリレプリカのブロッキングの問題は、CU10で導入されたVSSライターコードの更新の問題であることが確認されました。CU 13で解決されることを期待しています。暫定的な解決策は、VSSライターDLLを手動でPre-CU10 DLLに置き換えることです...

    BEGIN RANT-SACTION;

    残念ながら、MicrosoftはWindows 10の更新だけでなく、SQL ServerなどのエンタープライズミッションクリティカルなソフトウェアのQAを適切に繰り返し失敗しているようです。

    私は以前のサービスパックの戦略を大いに好みました。少なくとも、半ば焼き付けられた更新の不注意なリリースで、顧客に生産の危機とデータの損失を与える前に、それらを適切にテストする十分な時間がありました。

    COMMIT RANT-SACTION;
— SQLRaptor
ソース
2

ワーカースレッドを確認しましたか？通常、常にオンでは、より多くのワーカースレッドを使用して動作し、通常はデフォルト値では十分ではありません。常時オンの600個のデータベースで同じ問題が発生したため、インスタンスパラメーターにさらにスレッドを追加し、問題を修正しました。お役に立てれば！

— ゴンサロ・ビシオ
ソース
2
@Gonzaloこんにちは、アドバイスをありがとう。max_worker_threads設定角度についてはすでに説明しましたが、十分なスレッドがない場合によく見られる「no worker thread available」などのエラーは発生しませんでした。ボックスのデフォルトは1kスレッド未満でしたが、エラーへの影響は観察されず、徐々に2kに上げました。ワーカースレッドメトリックを収集します。最大でカウントされないAGスレッドを含め、平均で約1500個です。したがって、スレッドの制限にはほど遠い状態です。
— SQLRaptor
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.