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


9

Сегодня утром меня разбудило полное предупреждение журнала транзакций в одной из наших баз данных. Этот сервер всегда является кластером, а также подписчиком репликации транзакций. Я проверил 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 и не может очистить журнал.

Есть идеи, почему это происходит?

Ответы:


7

Если вы делаете это:

SELECT * FROM sys.databases

И log_reuse_wait_desc показывает AVAILABILITY_REPLICA, это означает, что SQL Server ожидает отправки данных журнала в одну из ваших реплик группы Always On Availability. Одна из реплик может отставать из-за медленной сети или вообще не работать.

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

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


Будет ли иметь значение, если для вторичного устройства установлен асинхронный режим? Если вторичное устройство выключено (ожидает исправления), будет ли основной журнал продолжать расти? Спасибо!
Майкл

Пока вторичное устройство все еще находится в AG (независимо от того, включено оно или выключено, синхронизировано или асинхронно), данные журнала будут накапливаться. В конце концов, когда вы снова включаете вторичное устройство, оно должно откуда-то получать свои данные, верно? Вот почему, если он не работает какое-то время, обычно лучше удалить его из AG и повторно инициализировать его из резервной копии.
Брент Озар
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.