web-dev-qa-db-ja.com

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

みなさん、こんにちは。ご協力ありがとうございます。 SQL Server 2017可用性グループで課題が発生しています。

背景

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

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

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

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

SQL Sentryを使用してサーバーを監視しており、物理的なボトルネックは観察されていません。すべての主要な指標は良いようです。 CPUは平均20％、IO時間は通常1ms未満、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でタイプごとに10Kを超えるエラーが発生した日について、先週の毎日のエラーの要約を次に示します（セカンダリは「プライマリとの接続が失われています...」を示しています）。

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」に変更しています。これは情報メッセージです。ユーザーの操作は必要ありません。

...状態が「セカンダリ」から「解決中」に変化するホストの中で。

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

Waits when severe burst of AG errors occur

約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-serveravailability-groupssql-server-2017
15
SQLRaptor

更新：

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

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

    BEGIN RANT-SACTION;

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

    私は以前のサービスパックの戦略を大いに好みました。少なくとも、半分焼きたてのアップデートを不注意にリリースすることで、本番環境の危機とデータ損失を顧客に与える前に、適切にテストする十分な時間がありました。

    COMMIT RANT-SACTION;
9
SQLRaptor

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

2
Gonzalo bissio