Nie można obciąć dziennika transakcji, log_reuse_wait_desc - AVAILABILITY_REPLICA

Dziś rano obudził mnie komunikat o logowaniu transakcji w jednej z naszych baz danych. Ten serwer jest klastrem Alwayson, a także transakcyjnym subskrybentem replikacji. Sprawdziłem log_reuse_wait_desc i zobaczyłem logbackup. Ktoś przypadkowo wyłączył zadania tworzenia kopii zapasowych dziennika 4 dni wcześniej, ponownie włączyłem zadanie tworzenia kopii zapasowej dziennika i dziennik został wyczyszczony. Od czwartej nad ranem pomyślałem, że pójdę do biura później tego ranka i będę unikać dziennika, który urósł do 400 GB.

10 rano - jestem w biurze i sprawdzam użycie kłody, zanim się zmniejszyłem i było to około 16%. Byłem zaskoczony i sprawdziłem log_reuse_wait_desc, który pokazał replikację. Byłem zdezorientowany, ponieważ był to subskrybent replikacji. Potem zobaczyliśmy, że db jest włączony dla CDC i pomyślałem, że może to być przyczyną, więc wyłączono CDC, a teraz log_reuse_wait_desc pokazuje AVAILABILITY_REPLICA.

Tymczasem wykorzystanie dzienników stale rośnie i obecnie wynosi 17%. Sprawdzam pulpit Alwayson i sprawdzam kolejkę wysłania i ponowienia, a oba są praktycznie zerowe. Nie jestem pewien, dlaczego ponowne użycie dziennika jest wyświetlane jako AVAILABILITY_REPLICA i nie mogę wyczyścić dziennika.

Jakiś pomysł dlaczego tak się dzieje?

Jeśli to zrobisz:

SELECT * FROM sys.databases

A log_reuse_wait_desc pokazuje AVAILABILITY_REPLICA, co oznacza, że ​​SQL Server czeka na przesłanie danych dziennika do jednej z twoich replik grupy Always On Availability. Jedna z replik może być opóźniona ze względu na powolną sieć lub może być całkowicie niedostępna.

Jeśli sprawdzisz pulpit nawigacyjny AG i nie widać kolejek, być może padłeś ofiarą wyczerpania wątku. Znanym problemem jest to, że pulpit nawigacyjny AG przestaje aktualizować się po wyczerpaniu wątku roboczego. Będziesz musiał sprawdzić status każdej repliki bezpośrednio, zamiast polegać na podstawowej. Uwaga Nicka w tym elemencie Connect mówi, że możesz po prostu zmienić właściwości repliki, aby zrestartować replikację, ale to nie zawsze działa (zwłaszcza jeśli masz w bazie repliki setki baz danych z dużą ilością danych, które należy wysłać, i ponowne uruchomienie replikacji może spowodować ponowne wyczerpanie wątku roboczego).

Jeśli ostatni facet skonfigurował replikę AG i nie powinna już istnieć, nadszedł czas, aby usunąć tę AG i / lub replikę. Uważaj tylko, aby aplikacje nie wskazywały nazwy odbiornika, aby połączyć się z serwerem SQL Server.