トランザクションログを切り捨てることができません、log_reuse_wait_desc-AVAILABILITY_REPLICA
今朝、私はデータベースの1つでトランザクションログがいっぱいになったという警告に目覚めました。このサーバーは、常時接続のクラスターであり、トランザクションレプリケーションサブスクライバーでもあります。 log_reuse_wait_descを確認したところ、logbackupが表示されました。 4日前に誰かが誤ってlogbackupジョブを無効にしていたため、ログバックアップジョブを再度有効にしたところ、ログがクリアされました。午前4時だったので、その朝遅くにオフィスに行って、ログが400GBに達したときにログを鳴らそうと思いました。
午前10時-オフィスにいて、縮小する前にログの使用状況を確認したところ、約16％でした。私は驚いて、複製を示したlog_reuse_wait_descを確認しました。これがレプリケーションサブスクライバーだったため、混乱しました。次に、dbがCDCに対して有効になっていることがわかり、それが原因である可能性があると考えたため、CDCを無効にし、log_reuse_wait_descにAVAILABILITY_REPLICAが表示されます。
一方、ログの使用量は着実に増加しており、現在は17％です。 alwaysonダッシュボードを確認し、送信済みキューとやり直しキューを確認しましたが、どちらもほぼゼロです。ログの再利用がAVAILABILITY_REPLICAと表示され、ログをクリアできない理由がわかりません。
なぜこれが起こっているのでしょうか？
これを行う場合：
SELECT * FROM sys.databases
そして、log_reuse_wait_descはAVAILABILITY_REPLICAを示します。これは、SQL ServerがログデータをAlways On可用性グループのレプリカの1つに送信するのを待っていることを意味します。ネットワークの速度が遅いため、レプリカの1つが遅れているか、完全にダウンしている可能性があります。
AGダッシュボードを確認してもキューが表示されない場合は、スレッドが使い果たされている可能性があります。 ワーカースレッドの枯渇後にAGダッシュボードの更新が停止することは既知の問題です。 に依存するのではなく、各レプリカのステータスを直接確認する必要があります。プライマリ。ニックは、この接続項目で、レプリカのプロパティを変更してレプリケーションを再開できると述べていますが、これは常に機能するとは限りません（特に、大量のデータを送信する必要があるレプリカに何百ものデータベースがある場合、レプリケーションを再開すると、ワーカースレッドが再び枯渇する可能性があります。）
最後の男がAGレプリカをセットアップし、それがもう存在しないことになっている場合は、そのAGやレプリカを削除する必要があります。 SQL Serverに接続するために、アプリがリスナー名を指していないことに注意してください。