Dlaczego szybki VPN wciąż spowalnia synchroniczne zatwierdzanie SQL

Otwórz sesję zapytania na serwerze podstawowym i zobacz, na co czeka prosty zapis. Jeśli baza należy do grupy dostępności z synchronicznym zatwierdzaniem, a serwer pomocniczy jest połączony, część tego oczekiwania opuszcza budynek: rekordy dziennika podróżują do repliki, są tam utwardzane, a wieść o tym utwardzeniu wraca, zanim zatwierdzenie się zakończy. Przepustowość nie skraca tej podróży tam i z powrotem. Poniższy opis śledzi potwierdzenie z ekranu na zdalny dysk i z powrotem.

Zacznij od typu oczekiwania na serwerze podstawowym

Zapis czekający na zdalnej replice pojawia się jako oczekiwanie związane z dziennikiem, a nie jako oczekiwanie procesora lub blokady, a czas trwania transakcji podąża za podróżą tam i z powrotem, a nie za liczbą wierszy. Wiele małych zatwierdzeń czyni to oczywistym, bo każde płaci za podróż osobno. Jedna operacja zbiorcza ukrywa ten sam koszt w jednym dłuższym potwierdzeniu.

Przed wyciągnięciem jakichkolwiek wniosków o łączu posortuj obciążenie według częstotliwości zatwierdzeń.

Przeczytaj stan repliki, zanim przeczytasz sieć. Istotne liczniki to kolejka wysyłania, kolejka redo i stan synchronizacji, a razem pokazują, czy serwer pomocniczy nadąża, czy zostaje z tyłu. Rosnąca kolejka wysyłania wskazuje na transport, a rosnąca kolejka redo na własną pracę lub pamięć masową serwera pomocniczego. To różne naprawy i żadna nie poprawia się przez dodanie przepustowości.

Śledź potwierdzenie aż do serwera pomocniczego

Przy synchronicznym zatwierdzaniu serwer podstawowy czeka na potwierdzenie, że odpowiedni dziennik został utwardzony na serwerze pomocniczym, zanim zgłosi zatwierdzenie jako zakończone. Utwardzony oznacza trwały w dzienniku, a nie odtworzony na stronach danych. Właśnie ta różnica wyjaśnia, dlaczego synchroniczny serwer pomocniczy może pozostawać w tyle w redo, a jednocześnie potwierdzać utwardzenie.

Przejdź ścieżkę po kolei i mierz każdy etap, a nie całość. Rekordy dziennika idą przez transport, serwer pomocniczy je zapisuje i opróżnia, a potwierdzenie wraca tą samą drogą. Opóźnienie transportu, harmonogram serwera pomocniczego i opóźnienie jego dysku dziennika trafiają do sumy, a tylko pierwsze należy do właściciela sieci. Serwer pomocniczy, którego objętość dziennika jest nasycona czymś innym, może rozciągnąć każde zatwierdzenie, podczas gdy łącze stoi bezczynnie.

SELECT ag.name AS ag_name, drs.database_id, drs.synchronization_state_desc,
       drs.log_send_queue_size, drs.redo_queue_size
FROM sys.dm_hadr_database_replica_states AS drs
JOIN sys.availability_groups AS ag ON ag.group_id = drs.group_id;

Zrób ten zrzut przed i po reprezentatywnym zapisie, a nie raz w spokojne popołudnie. Różnica mówi, która kolejka się przesunęła, gdy zatwierdzenie czekało.

Mierz ścieżkę, nie łącze

Test przepustowości mierzy pojemność między dwoma punktami, które nie są twoimi replikami, pod obciążeniem, które nie jest twoją pracą. Poproś właściciela sieci o opóźnienie i straty na rzeczywistej ścieżce repliki, gdy płynie rzeczywisty ruch, w obu kierunkach. Straty liczą się tu bardziej niż pojemność, bo utracony segment kosztuje retransmisję, a każde zatwierdzenie czeka na jedno potwierdzenie. Łącze, które w teście pobierania wygląda świetnie, może wciąż nie pasować do gadatliwego wzorca zatwierdzeń.

Podczas pomiaru zachowaj nienaruszone bezpieczeństwo transportu bazy i kontrolę dostępu. Pomiar ścieżki nigdy nie jest powodem, by je omijać.

Koreluj czasy z licznikami, a nie z intuicją. Jeśli kolejka wysyłania pozostaje pusta, a zatwierdzenie nadal czeka, opóźnienie jest w potwierdzeniu lub w opróżnianiu serwera pomocniczego. Jeśli kolejka wysyłania stale rośnie, ograniczeniem jest transport lub pojemność. Zapisz, która obserwacja poparła wniosek, aby następna osoba mogła powtórzyć pomiar, a nie spór.

Co naprawdę zmienia tryb asynchroniczny

Asynchroniczne zatwierdzanie usuwa oczekiwanie na potwierdzenie utwardzenia od serwera pomocniczego, dlatego zapisy stają się szybsze i dlatego zmienia się twoja pozycja trwałości. Serwer podstawowy potwierdza transakcję bez tego zdalnego potwierdzenia. Serwer pomocniczy może wtedy pozostawać z tyłu, a to opóźnienie jest ekspozycją.

Jeśli serwer podstawowy zostanie utracony, zanim dziennik dotrze do użytecznego celu przełączenia awaryjnego, wymuszenie usługi na tej replice odrzuca transakcje, o których aplikacja już została poinformowana, że zostały zatwierdzone.

To decyzja o punkcie odzyskiwania i należy do właściciela bazy, a nie do przeglądu wydajności. Najpierw ustaw tolerowane okno utraty danych, wybierz tryb, który je spełnia, a potem optymalizuj w tych granicach. Opcje zachowujące ochronę synchroniczną obejmują usuwanie zbędnych podróży zatwierdzenia tam, gdzie aplikacja na to pozwala, naprawę zmierzonego wąskiego gardła transportu lub pamięci masowej oraz przeniesienie repliki, aby potwierdzenie pokonywało mniejszy dystans. Rozważ je wobec wymagania trwałości, z którym zacząłeś i które się nie zmieniło.