Невозможно усечь журнал транзакций, log_reuse_wait_desc - AVAILABILITY_REPLICA

Сегодня утром меня разбудило полное предупреждение журнала транзакций в одной из наших баз данных. Этот сервер всегда является кластером, а также подписчиком репликации транзакций. Я проверил log_reuse_wait_desc, и он показал logbackup. Кто-то случайно отключил задания резервного копирования 4 днями ранее, я снова включил задание резервного копирования журнала, и журнал был очищен. Так как это было 4 утра, я думал, что я пойду в офис позже тем утром и уклонюсь от журнала, поскольку он вырос до 400 ГБ.

10 утра - я нахожусь в офисе, и я проверяю использование журнала перед сокращением, и это было около 16% Я был удивлен и проверил log_reuse_wait_desc, который показал репликацию. Я был смущен, потому что это был подписчик репликации. Затем мы увидели, что база данных была включена для 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 Availability. Одна из реплик может отставать из-за медленной сети или вообще не работать.

Если вы проверите панель мониторинга AG, и она не показывает очередей, возможно, вы стали жертвой исчерпания потока. Известно, что панель мониторинга AG перестает обновляться после исчерпания рабочего потока. Вам нужно будет проверить состояние каждой реплики напрямую, а не полагаться на основную. Примечание Ника в этом элементе Connect говорит, что вы можете просто изменить свойства реплики, чтобы перезапустить репликацию, но это не всегда работает (особенно если у вас есть сотни баз данных на реплике с большим объемом данных, которые необходимо отправить, и перезапуск репликации может просто снова вызвать истощение рабочего потока.)

Если последний парень создал реплику AG, и она больше не должна существовать, то пришло время удалить эту AG и / или реплику. Просто будьте осторожны, чтобы приложения не указывали на имя слушателя, чтобы подключиться к вашему SQL Server.