Odzyskiwanie danych w Always On

Odzyskiwanie danych w Always On opiera się na przełączeniu na sprawną replikę, a nie na przywracaniu kopii zapasowej.

Always On jako mechanizm ciągłości dostępu do danych

Odzyskiwanie danych w technologii Always On Availability Groups dla Microsoft SQL Server polega przede wszystkim na przełączeniu obsługi bazy na inną replikę grupy dostępności. Replika podstawowa przyjmuje zapisy, a repliki pomocnicze utrzymują własne kopie baz użytkownika. Jeżeli podstawowa replika przestanie działać, możliwe jest wykonanie przełączenia roli na replikę pomocniczą, która ma dostępny stan bazy i może przejąć obsługę aplikacji. W takim scenariuszu nie odtwarza się całej bazy z kopii zapasowej, ponieważ druga replika zawiera już dane przesyłane z repliki podstawowej.

Always On nie jest jednak pojedynczą kopią zapasową ani zamiennikiem procedury backupu. Jest mechanizmem wysokiej dostępności i odzyskiwania po awarii instancji lub serwera SQL Server. Jego działanie opiera się na przesyłaniu rekordów dziennika transakcji z podstawowej bazy danych do baz pomocniczych. Replika pomocnicza odtwarza otrzymane rekordy w swojej kopii bazy. Dzięki temu po przełączeniu można zachować dostęp do danych bez wielogodzinnego odtwarzania pełnej kopii, kopii różnicowej i kolejnych kopii dziennika.

Przesyłanie dziennika i stan repliki pomocniczej

W grupie dostępności SQL Server repliki mogą pracować w trybie synchronicznego albo asynchronicznego zatwierdzania. Przy synchronicznym zatwierdzaniu transakcja jest uznawana za zatwierdzoną dopiero po zapisaniu odpowiednich rekordów dziennika na podstawowej oraz synchronicznej pomocniczej replice. Ogranicza to ryzyko utraty ostatnich zatwierdzonych transakcji podczas kontrolowanego przełączenia, ale może zwiększać czas oczekiwania na zapis, ponieważ podstawowa replika zależy od potwierdzenia drugiego serwera.

W trybie asynchronicznym podstawowa replika nie czeka na pełne potwierdzenie odebrania i odtworzenia dziennika przez replikę pomocniczą. Takie ustawienie jest stosowane między innymi wtedy, gdy repliki znajdują się w odległych lokalizacjach albo połączenie między nimi ma większe opóźnienia. W razie awarii podstawowej repliki pomocnicza może więc nie zawierać wszystkich ostatnich transakcji. Przełączenie na nią przywraca działanie bazy, ale może wiązać się z utratą zmian, które nie zostały jeszcze przesłane lub odtworzone.

Przed przełączeniem trzeba ocenić stan synchronizacji, opóźnienie przesyłania dziennika oraz opóźnienie jego odtwarzania. Istotne są również dostępność punktu końcowego grupy dostępności, stan usługi SQL Server oraz możliwość nawiązania połączenia z repliką. Sama obecność bazy pomocniczej nie oznacza, że jest ona gotowa do bezpiecznego przejęcia roli. Baza może być w stanie synchronizacji, ponownej synchronizacji albo zawieszenia przesyłania danych. W takiej sytuacji przełączenie może zakończyć się utratą części danych lub niedostępnością bazy.

Przełączenie roli a właściwe odtwarzanie utraconych danych

Przełączenie na replikę pomocniczą rozwiązuje problem niedostępności podstawowego źródła danych, lecz nie naprawia każdego rodzaju uszkodzenia. Jeżeli użytkownik przypadkowo usunie rekordy, aplikacja zapisze błędne wartości albo logiczne uszkodzenie zostanie powielone przez mechanizm synchronizacji, zmiana repliki może nie przywrócić poprawnego stanu. Podobnie awaria obejmująca wszystkie repliki grupy dostępności nie może zostać usunięta przez zwykły failover. W takich przypadkach potrzebne jest odtworzenie danych z kopii zapasowej lub zastosowanie innej procedury odzyskiwania właściwej dla SQL Server.

Kopie zapasowe pozostają potrzebne do odtwarzania punktu w czasie, odbudowy uszkodzonej repliki, odzyskania przypadkowo usuniętych danych oraz ochrony przed awarią całego środowiska. W bazie działającej w modelu pełnego odzyskiwania ważne jest zachowanie ciągłości dziennika transakcji. Kopie dziennika umożliwiają odtworzenie zmian do określonego momentu, o ile istnieje kompletna sekwencja kopii i nie doszło do przerwania łańcucha logów. Always On może skrócić przerwę w dostępie do usługi, ale nie zapewnia samodzielnie historycznych punktów odtworzenia.

W praktyce procedura powinna rozróżniać awarię usługi od utraty lub zniekształcenia danych. Przy awarii pojedynczej repliki można rozważyć automatyczne albo ręczne przełączenie, zależnie od konfiguracji trybu dostępności i warunków failover. Przy błędzie logicznym należy najpierw zabezpieczyć stan bieżący, ustalić moment wystąpienia problemu i wybrać właściwy punkt odtworzenia. Odtworzonej bazy nie należy bezpośrednio traktować jako kolejnej zdrowej repliki bez sprawdzenia zgodności konfiguracji, pełności danych i poprawności synchronizacji.

Weryfikacja gotowości do odzyskania w SQL Server

Ocena gotowości wymaga sprawdzenia konfiguracji grupy dostępności, ról replik, trybu dostępności oraz bieżących stanów synchronizacji. Administrator może analizować między innymi widoki dynamicznego zarządzania SQL Server dotyczące replik i baz w grupie dostępności, w tym informacje o roli repliki, stanie połączenia, stanie synchronizacji i zalegających rekordach dziennika. Należy również sprawdzić, czy aplikacja korzysta z prawidłowego listenera grupy dostępności, ponieważ przełączenie roli nie gwarantuje poprawnego połączenia, jeśli aplikacja używa na stałe nazwy lub adresu przypisanego do konkretnego serwera.

Po przełączeniu należy zweryfikować możliwość wykonywania odczytów i zapisów, stan bazy w nowej replice podstawowej, działanie zależności aplikacyjnych oraz dostępność zadań SQL Server Agent. Trzeba także potwierdzić, że poprzednia replika nie przyjmuje równoległych zapisów i że po odzyskaniu łączności może zostać ponownie dołączona do grupy. Wymaga to sprawdzenia przesyłania oraz odtwarzania dziennika, a nie tylko samego statusu usługi Windows. W środowisku serwerowym diagnostyka powinna obejmować także przyczynę awarii: błędy dysków, problemy z siecią, zatrzymanie procesu SQL Server, brak miejsca na woluminie lub uszkodzenie plików bazy.

Bezpieczne odzyskiwanie wymaga udokumentowanego planu określającego, kiedy dopuszczalne jest przełączenie automatyczne, kiedy potrzebna jest decyzja operatora oraz jaki poziom utraty danych jest akceptowalny. Po zakończeniu operacji należy odnotować wybraną replikę, czas przełączenia, stan synchronizacji i zakres ewentualnych nieprzesłanych transakcji. Takie informacje pozwalają odróżnić odzyskanie dostępności bazy od pełnego odzyskania danych historycznych z kopii zapasowych.