SQL Server 2017 z 500 bazami danych - częste AG rozłącza się od CU9

Witam wszystkich i z góry dziękuję za pomoc. Mamy problemy z grupami dostępności programu SQL Server 2017.

tło

Firma jest detalicznym oprogramowaniem zaplecza B2B. Około 500 baz danych dla pojedynczych najemców i 5 wspólnych baz danych używanych przez wszystkich najemców. Charakterystyka obciążenia jest czytana głównie, a większość baz danych ma bardzo niską aktywność.

Fizyczne serwery produkcyjne hostowane w tej samej lokalizacji zostały niedawno uaktualnione z SQL Server 2014 Enterprise na Windows Server 2012 we wspólnej konfiguracji SAN / FCI do SQL Server 2017 Enterprise na Windows Server 2016 na 2 gniazdach / 32 rdzeniach / 768 GB pamięci RAM i lokalnych Dyski SSD korzystające z AlwaysOn AG. Ruch AG wykorzystuje dedykowane porty 10G NIC ze skrzyżowanym połączeniem kablowym.

Wymagają, aby wszystkie bazy danych przełączyły się w tryb failover, więc musieli umieścić je wszystkie w jednym AG. Jest to pojedyncza, nieczytelna replika synchroniczna na identycznym serwerze.

Nowe serwery są w produkcji od czerwca 2018 r. Zainstalowano najnowsze CU (wówczas CU7) i aktualizacje systemu Windows, a system działał dobrze. Około miesiąca później, po aktualizacji serwerów z CU7 na CU9, zaczęli zauważać następujące wyzwania, wymienione w kolejności priorytetów.

Monitorowaliśmy serwery za pomocą SQL Sentry i nie zaobserwowaliśmy żadnych fizycznych wąskich gardeł. Wszystkie kluczowe wskaźniki wydają się dobre. Procesor ma średnio 20%, czasy We / Wy zwykle mniej niż 1 ms, pamięć RAM nie jest w pełni wykorzystana, a sieć <1%.

Wyzwania

Objawy wydają się poprawiać po przełączeniu awaryjnym, ale powracają w ciągu kilku dni, niezależnie od tego, który serwer jest główny - objawy są identyczne na obu serwerach.

1. Sporadyczne przerwy w działaniu klienta i awarie połączeń, takie jak

   ... wystąpił błąd podczas nawiązywania połączenia ...

   lub

   Upłynął limit czasu wykonania

   Czasami będą trwać do 40 sekund, a następnie ustąpią.

2. Wykonanie zadania tworzenia kopii zapasowej dziennika transakcji trwa 10 razy dłużej niż wcześniej. Wcześniej tworzenie kopii zapasowych dzienników wszystkich 500 baz danych trwało 2-3 minuty, teraz zajmuje to 15–25. Sprawdziliśmy, że sama kopia zapasowa działa dobrze przy dobrej przepustowości. Występuje jednak niewielkie opóźnienie po zakończeniu tworzenia kopii zapasowej jednego dziennika i przed rozpoczęciem następnego. zaczyna się bardzo nisko, ale w ciągu dnia lub dwóch dochodzi do 2-3 sekund. Pomnożone przez 500 baz danych, i jest różnica.

3. Czasami niektóre pozornie przypadkowe bazy danych blokują się w stanie „Brak synchronizacji” po ręcznym przełączeniu awaryjnym. Jedynym sposobem rozwiązania tego jest ponowne uruchomienie usługi SQL Server w replice dodatkowej lub usunięcie tych baz danych i ponowne przyłączenie się do AG.

4. Kolejny problem wprowadzony przez CU10 (nierozwiązany w CU11): Połączenia z dodatkowym limitem czasu podczas blokowania na master.sys.dat bazach danych, a nawet niemożność użycia eksploratora obiektów SSMS do repliki dodatkowej. Wydaje się, że główną przyczyną jest blokowanie przez program zapisujący VSS programu Microsoft SQL Server, który wydaje następujące zapytanie:

   select name, 
          recovery_model_desc, 
          state_desc, 
          CONVERT(integer, is_in_standby), 
          ISNULL(source_database_id,0) 
     from master.sys.databases

Spostrzeżenia

Wydaje mi się, że w dziennikach błędów znalazłem pistolet do palenia. Dzienniki błędów są pełne komunikatów AG, które są oznaczone jako „wyłącznie informacyjne”, ale wygląda na to, że wcale nie są normalne, i istnieje bardzo silna korelacja ich częstotliwości z błędami aplikacji.

Błędy są kilku rodzajów i występują w sekwencjach:

• DbMgrPartnerCommitPolicy :: SetSyncState: GUID

• DbMgrPartnerCommitPolicy :: SetSyncAndRecoveryPoint: GUID

• Połączenie AlwaysOn Availability Groups z dodatkową bazą danych zakończone dla podstawowej bazy danych „XYZ” na replice dostępności „DB” o identyfikatorze repliki: {GUID}. To jest tylko komunikat informacyjny. Nie jest wymagana żadna akcja użytkownika.

• Połączenie AlwaysOn Availability Groups z dodatkową bazą danych ustanowione dla podstawowej bazy danych „ABC” na replice dostępności „DB” o identyfikatorze repliki: {GUID}. To jest tylko komunikat informacyjny. Nie jest wymagana żadna akcja użytkownika.

Czasami jest ich dziesiątki tysięcy.

W tym artykule omówiono ten sam typ sekwencji błędów w SQL 2016 i tam stwierdzono, że jest on nieprawidłowy. To wyjaśnia również zjawisko „niezsynchronizowania” po przełączeniu awaryjnym. Omawiany problem dotyczył 2016 r. I został naprawiony wcześniej w tym roku w jednostce kalkulacyjnej. jest to jednak jedyne istotne odniesienie, które udało mi się znaleźć dla pierwszych 2 rodzajów komunikatów, inne niż odniesienia do komunikatów automatycznego początkowego inicjowania, które nie powinny mieć miejsca w tym przypadku, ponieważ grupa AG jest już ustalona.

Oto podsumowanie dziennych błędów w zeszłym tygodniu, dla dni, w których wystąpił błąd> 10 000 błędów dla typu PODSTAWOWEGO (wtórne pokazuje „utratę połączenia z pierwotnym ...”):

Date        Message Type (First 50 characters)                  Num Errors
10/8/2018   DbMgrPartnerCommitPolicy::SetSyncAndRecoveryPoint:  61953
10/3/2018   DbMgrPartnerCommitPolicy::SetSyncAndRecoveryPoint:  56812
10/4/2018   DbMgrPartnerCommitPolicy::SetSyncAndRecoveryPoint:  27951
10/2/2018   DbMgrPartnerCommitPolicy::SetSyncAndRecoveryPoint:  24158
10/7/2018   DbMgrPartnerCommitPolicy::SetSyncAndRecoveryPoint:  14904
10/8/2018   Always On Availability Groups connection with seco  13301
10/3/2018   DbMgrPartnerCommitPolicy::SetSyncState: 783CAF81-4  11057
10/3/2018   Always On Availability Groups connection with seco  10080

Od czasu do czasu widzimy też „dziwne” wiadomości, takie jak:

Baza danych grupy dostępności „DB” zmienia role z „WTÓRNE” na „WTÓRNE”, ponieważ sesja dublowania lub grupa dostępności uległy awarii z powodu synchronizacji ról. To jest tylko komunikat informacyjny. Nie jest wymagana żadna akcja użytkownika.

... wśród wielu zmieniających się stanów z „SECONDARY” na „RESOLVING”.

Po ręcznym przełączeniu awaryjnym system może działać przez kilka dni bez jednego komunikatu tego typu i nagle, bez wyraźnego powodu, otrzymamy tysiące naraz, co z kolei powoduje, że serwer przestaje odpowiadać i powoduje aplikację przekroczenia limitu czasu połączenia. Jest to krytyczny błąd, ponieważ niektóre z jego aplikacji nie zawierają mechanizmu ponownej próby, dlatego mogą utracić dane. Kiedy pojawia się taka seria błędów, następujące typy oczekiwania podskakują. To pokazuje oczekiwania zaraz po tym, jak AG wydaje się utracić połączenie ze wszystkimi bazami danych jednocześnie:

Około 30 sekund później wszystko wraca do normy pod względem oczekiwań, ale komunikaty AG wciąż zalewają dzienniki błędów w różnym tempie i w różnych porach dnia, pozornie przypadkowych, w tym poza godzinami szczytu. Jednoczesny wzrost obciążenia pracą podczas tych wybuchów błędów oczywiście pogarsza sytuację. Jeśli tylko kilka baz danych zostanie rozłączonych, zwykle nie powoduje to przekroczenia limitu czasu połączeń, ponieważ jest ono rozwiązywane wystarczająco szybko samodzielnie.

Próbowaliśmy zweryfikować, że rzeczywiście CU9 spowodował problem, ale udało nam się obniżyć oba węzły tylko do CU9. Próby obniżenia jednego z węzłów do CU8 spowodowały, że węzeł utknął w stanie „Rozwiązywanie”, pokazując ten sam błąd w dzienniku:

Nie można odczytać trwałej konfiguracji grupy dostępności Always On z odpowiednim identyfikatorem zasobu „…. Trwała konfiguracja została napisana przez SQL Server w wyższej wersji, który obsługuje replikę podstawowej dostępności. Zaktualizuj lokalną instancję SQL Server, aby lokalna replika dostępności stała się repliką dodatkową.

Oznacza to, że będziemy musieli wprowadzić czas przestoju, aby móc jednocześnie obniżyć oba węzły do ​​CU8. Sugeruje to również, że nastąpiła poważna aktualizacja AG, która może wyjaśnić to, czego doświadczamy.

Próbowaliśmy już dostosowywać max_worker_threads z domyślnej wartości 0 (= 960 w naszym pudełku na podstawie tego artykułu ) stopniowo do 2000 bez zauważalnego wpływu na błędy.

Co możemy zrobić, aby rozwiązać problemy z rozłączeniem AG? Czy ktoś ma podobne problemy? Czy inne osoby z dużą liczbą baz danych w AG mogą widzieć podobne komunikaty w dzienniku błędów SQL zaczynającym się od CU9 lub CU8?

Z góry dziękuję za wszelką pomoc!

Aktualizacja:

1. Potwierdzono, że rozłączenia grupy częstej dostępności były regresją wprowadzoną przez CU9 i rozwiązano je po zainstalowaniu CU12.

2. Potwierdzono, że problemy z blokowaniem wtórnej repliki stanowią problem z aktualizacją kodu programu piszącego VSS, który został wprowadzony w CU10. Mamy nadzieję, że zostanie to rozwiązane w CU 13. Tymczasowym rozwiązaniem jest ręczne zastąpienie bibliotek DLL programu zapisującego VSS bibliotekami DLL wcześniejszymi niż CU10 ...

   BEGIN RANT-SACTION;

   Niestety wydaje się, że Microsoft wielokrotnie nie przeprowadza odpowiedniej kontroli jakości nie tylko aktualizacji systemu Windows 10, ale także oprogramowania o znaczeniu krytycznym dla przedsiębiorstw, takiego jak SQL Server.

   Zdecydowanie wolałem ich poprzednią strategię dotyczącą pakietów serwisowych, przynajmniej mieli wystarczająco dużo czasu, aby je odpowiednio przetestować, zanim spowodują kryzys produkcyjny i utratę danych dla swoich klientów dzięki nieostrożnemu wydaniu częściowo upieczonych aktualizacji.

   COMMIT RANT-SACTION;

Czy sprawdziłeś wątki robocze? Zwykle zawsze używa się więcej wątków roboczych do pracy, a normalnie wartość domyślna nie jest wystarczająca. Miałem ten sam problem z 600 bazami danych zawsze włączonymi, więc dodajemy więcej wątków do parametru instancji i to naprawiło nasz problem. Mam nadzieję że to pomoże!