SQL可用性グループからセカンダリレプリカを削除すると、ログファイルが大きくなる
予期しないハードウェアエラーが発生したため、メンテナンスのためにセカンダリレプリカを削除する必要がありました。これは実際にはストレージの問題が原因であり、より高いレベルで、セカンダリインスタンス用に新しいストレージシステムを購入することが決定されました。この時点で、納品と設置から数週間です。
これは、2つのアクティブなインスタンスでFCIも使用するシステム上にありました。
両方の可用性グループからセカンダリレプリカを正常に削除できたので、これを正しく行ったと思いました（UIやAGダッシュボードに表示されなくなったためです。ただし、AGの1つ、すべてのログファイルが増加しています。sys.databasesをクエリして、そのインスタンスのlog_reuse_wait_descを見ると、'AVAILABILITY_REPLICA'と表示されています
リスナーがアクティブに使用されており、多数のweb.configsとその他の構成エントリの再構成が必要になるため、AGを削除したくない。しかし、ログファイルの増加についても少し心配しています。
なぜ、1つのAGでは成長していないか、log_reuse_wait_descがAVAILABILITY_REPLICAであるように見えませんが、他のAGでは成長しているのですか？
質問は間違った仮定を持っていると思います。
データベースを削除せずに、ログファイルが「AVAILABILITY_REPLICA」で動かなくなることなく、データベースのAGで単一の（プライマリ）レプリカサーバーをアクティブに保つ方法はありますか？
...
リスナーがアクティブに使用されており、多数のweb.configsおよびその他の構成エントリの再構成が必要になるため、AGを削除しない方がよいでしょう。しかし、ログファイルの増加についても少し心配しています。
単一ノードでAGを実行している場合は、AGからデータベースを完全に削除しても、リスナーを介してデータベースに接続できます（クラスター化部分が強制的にオンラインであるか、動的クォーラムでWindows 2012+を使用している場合）。
アプリケーションを使用しない通常の接続では、リスナーはサーバーのダムエイリアスとして機能します。接続しているデータベースがAGの一部であるかどうかなどはチェックしません。
回避策は、AGからDBを削除し、ログをクリアしてAGに追加し直すことです。