Synchronous Commit

Synchronous Commit to tryb replikacji potwierdzający transakcję dopiero po jej zapisaniu również na replice wtórnej.

Jak działa Synchronous Commit w SQL Server Always On

Synchronous Commit to tryb pracy repliki w grupie dostępności Always On w systemie Microsoft SQL Server. Baza podstawowa, określana jako primary replica, zapisuje zmiany w dzienniku transakcji i przekazuje rekordy dziennika do repliki wtórnej, czyli secondary replica. Transakcja nie otrzymuje potwierdzenia dla aplikacji od razu po lokalnym zapisie. SQL Server czeka, aż replika wtórna otrzyma odpowiednie rekordy dziennika i utrwali je w swoim pliku dziennika transakcji.

Po pomyślnym utrwaleniu dziennika na replice wtórnej wysyłane jest potwierdzenie do repliki podstawowej. Dopiero wtedy klient otrzymuje potwierdzenie zatwierdzenia transakcji. Mechanizm dotyczy zapisu dziennika transakcji, a nie natychmiastowego odtworzenia zmienionych stron danych na replice wtórnej. Odtwarzanie dziennika przez proces redo może następować chwilę później, dlatego samo potwierdzenie synchronous commit nie oznacza, że zapytania odczytujące dane z repliki wtórnej w każdej chwili pokażą dokładnie ten sam stan co replika podstawowa.

Utrwalanie dziennika a potwierdzenie transakcji

W SQL Server Always On każda replika dostępności ma określony tryb dostępności. Dla trybu Synchronous Commit istotna jest kolejność operacji: zmiana jest rejestrowana w dzienniku transakcji na replice podstawowej, rekordy dziennika są przesyłane do repliki wtórnej, a następnie dziennik wtórny jest zapisywany na trwałym nośniku. Po otrzymaniu potwierdzenia utrwalenia SQL Server może zakończyć zatwierdzanie transakcji wobec aplikacji.

Rozwiązanie zwiększa odporność na utratę danych wynikającą z awarii pojedynczego serwera, ponieważ zatwierdzone rekordy dziennika znajdują się również na drugiej replice. Nie należy jednak utożsamiać tego mechanizmu z niezależną kopią zapasową. Obie repliki mogą być dotknięte wspólną awarią infrastruktury, błędem logicznym, usunięciem danych przez użytkownika albo wadliwą transakcją. Ochronę zapewnianą przez replikację uzupełnia się więc kopiami zapasowymi oraz sprawdzaniem możliwości odtworzenia bazy.

Koszt opóźnienia i sygnały diagnostyczne

Najbardziej zauważalnym skutkiem Synchronous Commit jest zwiększenie czasu oczekiwania na zatwierdzenie transakcji. Opóźnienie zależy między innymi od odległości między serwerami, jakości połączenia, przepustowości sieci, czasu zapisu dziennika na nośniku repliki wtórnej oraz bieżącego obciążenia obu instancji SQL Server. Jeżeli replika wtórna odpowiada wolno, aplikacja również może dłużej czekać na zakończenie operacji zapisu.

Podczas analizy problemu warto rozróżniać kilka stanów. Send queue wskazuje rekordy dziennika oczekujące na przesłanie z repliki podstawowej do wtórnej, natomiast redo queue opisuje rekordy już przesłane, lecz jeszcze nieodtworzone na replice wtórnej. Duża kolejka wysyłania może wskazywać na problem z transportem lub wydajnością dziennika po stronie primary replica. Duża kolejka redo może oznaczać, że secondary replica nie nadąża z odtwarzaniem zmian. Przydatne są również informacje o stanie synchronizacji bazy, stanie połączenia replik oraz czasie oczekiwania związanym z komunikacją między replikami.

Dobór trybu dla środowiska SQL Server

Synchronous Commit stosuje się wtedy, gdy ważniejsza od minimalnego czasu odpowiedzi jest ograniczona utrata ostatnich zatwierdzonych transakcji po awarii repliki podstawowej. W konfiguracji Always On tryb ten może współpracować z automatycznym przełączaniem awaryjnym, ale sama nazwa trybu nie wystarcza do uznania całej konfiguracji za gotową do failoveru. Znaczenie mają także stan synchronizacji baz, poprawność konfiguracji grupy dostępności, zgodność wersji i edycji SQL Server, dostępność punktów końcowych oraz bieżąca kondycja obu replik.

Jeżeli opóźnienia zapisu stają się zbyt duże, diagnoza powinna obejmować aplikację, zapytania powodujące intensywne zapisy, pliki dziennika transakcji, wydajność podsystemu dyskowego, sieć oraz mechanizmy Always On. Zmiana trybu na asynchronous commit może ograniczyć wpływ opóźnień repliki wtórnej na aplikację, ale zmienia poziom ochrony danych, ponieważ potwierdzenie transakcji może nastąpić przed utrwaleniem dziennika na replice wtórnej. Wybór trybu jest więc decyzją dotyczącą konkretnej architektury SQL Server, wymaganej odporności i dopuszczalnego opóźnienia.