Restore w środowisku Always On

Restore w środowisku Always On wymaga uwzględnienia stanu grupy dostępności i synchronizacji replik.

Znaczenie operacji restore w grupie Always On

Restore w środowisku Always On Availability Groups w programie Microsoft SQL Server nie jest zwykłym odtworzeniem pojedynczej bazy na dowolnym serwerze. Baza uczestnicząca w grupie dostępności ma replikę podstawową oraz jedną lub więcej replik pomocniczych. Każda replika utrzymuje własną kopię danych i dziennika transakcji, a mechanizm grupy przekazuje rekordy dziennika z repliki podstawowej do pomocniczych. Przed rozpoczęciem odtwarzania trzeba ustalić, która replika jest aktualnie podstawowa, czy baza ma stan SYNCHRONIZED albo SYNCHRONIZING oraz czy grupa działa w stanie PRIMARY_NORMAL lub SECONDARY_NORMAL. Informacje te można sprawdzić w widokach dynamicznego zarządzania, między innymi sys.dm_hadr_database_replica_states i sys.dm_hadr_availability_replica_states.

Operacja restore może dotyczyć odtworzenia bazy do grupy dostępności, przygotowania nowej repliki pomocniczej albo odzyskania danych po awarii. Nie należy przywracać kopii bezpośrednio na bazę, która jest aktywnym uczestnikiem grupy, bez wcześniejszego zaplanowania wpływu tej czynności na stan grupy. SQL Server wymaga zachowania zgodności łańcucha kopii zapasowych i dziennika transakcji. Odtwarzana baza musi mieć właściwy identyfikator oraz strukturę zgodną z bazą, która ma zostać dołączona do grupy. W praktyce restore jest więc częścią procedury wysokiej dostępności, a nie wyłącznie poleceniem służącym do skopiowania pliku bak.

Przygotowanie kopii i kolejności odtwarzania

Podstawowa sekwencja odtwarzania bazy SQL Server obejmuje kopię pełną, opcjonalną kopię różnicową oraz kolejne kopie dziennika transakcji. Kopię pełną odtwarza się z opcją NORECOVERY, jeżeli po niej mają zostać zastosowane następne kopie. Ta opcja pozostawia bazę w stanie przywracania i pozwala kontynuować łańcuch restore. Kopia różnicowa musi odnosić się do tej samej kopii bazowej, a dzienniki transakcji muszą być stosowane bez przerw w kolejności czasowej. Zakończenie odtwarzania przez WITH RECOVERY powoduje wykonanie fazy odzyskiwania i zamyka możliwość zastosowania kolejnych kopii w tym samym ciągu.

Przed przywróceniem należy zweryfikować pliki backupu poleceniem RESTORE HEADERONLY oraz zawartość kopii przez RESTORE FILELISTONLY. Warto również sprawdzić, czy kopia zawiera właściwą bazę, czy nie jest uszkodzona oraz jaki jest zakres LSN zapisany w kopiach dziennika. W grupie Always On istotne jest, aby kopie dziennika pochodziły z kompatybilnego łańcucha i obejmowały transakcje potrzebne do doprowadzenia repliki do tego samego punktu odzyskiwania. Jeżeli baza ma zostać dodana jako replika pomocnicza, odtworzenie jej kopii pełnej i dzienników wykonuje się zwykle na serwerze pomocniczym z użyciem NORECOVERY, a następnie dołącza bazę do grupy.

Synchronizacja repliki po restore

Po przygotowaniu bazy pomocniczej sama obecność odtworzonych danych nie oznacza jeszcze, że replika jest gotowa do pracy. Baza musi zostać dołączona do odpowiedniej grupy dostępności, a SQL Server musi rozpocząć przesyłanie i ponowne odtwarzanie rekordów dziennika z repliki podstawowej. Stan NOT SYNCHRONIZING wskazuje, że synchronizacja nie zachodzi; przyczyną może być brak połączenia endpointu Always On, problem z uprawnieniami, niedostępne pliki, zatrzymana baza lub niezgodność konfiguracji. Stan SYNCHRONIZING oznacza trwające przesyłanie albo odtwarzanie dziennika, natomiast SYNCHRONIZED potwierdza, że replika pomocnicza jest zsynchronizowana z podstawową w zakresie wymaganym przez tryb synchroniczny.

Przy odtwarzaniu po awarii trzeba rozróżnić przełączenie awaryjne od pełnego restore. Jeżeli replika pomocnicza zawiera wszystkie wymagane transakcje i jest dostępna, kontrolowane przełączenie może ograniczyć utratę danych. Jeżeli jednak baza została uszkodzona albo nie ma aktualnej repliki, konieczne jest odtworzenie z kopii oraz zastosowanie dzienników do uzgodnionego punktu w czasie. Przywrócenie bazy do działania poza grupą może wymagać usunięcia jej z grupy, odtworzenia kopii z WITH RECOVERY, a następnie ponownej konfiguracji ochrony wysokiej dostępności. Po zakończeniu należy sprawdzić role replik, stan baz, opóźnienie dziennika oraz możliwość wykonania kolejnych kopii zapasowych.

Weryfikacja poprawności i tok diagnostyki

Bezpośrednio po restore należy potwierdzić, że odtworzona baza ma oczekiwany stan i nie zgłasza błędów odzyskiwania. W SQL Server pomocne są komunikaty z dziennika błędów, historia operacji backupu i restore oraz widoki sys.databases, sys.availability_databases_cluster i widoki HADR. Należy zweryfikować, czy baza nie pozostaje w stanie RECOVERING, RESTORING albo SUSPECT, czy replika ma właściwą rolę oraz czy synchronizacja nie zatrzymała się na konkretnym numerze LSN. Sam fakt pomyślnego wykonania polecenia restore nie potwierdza integralności logicznej wszystkich tabel i transakcji.

Procedura powinna obejmować także test odczytu danych, kontrolę dostępności aplikacji oraz sprawdzenie, czy połączenia kierowane przez listener trafiają do aktualnej repliki podstawowej. W przypadku problemów trzeba rozdzielić błąd kopii zapasowej, błąd samego odtwarzania, błąd transportu dziennika i błąd konfiguracji grupy. Przydatne są komunikaty o przerwaniu łańcucha logów, braku dostępu do pliku backupu, niezgodności wersji lub braku miejsca na woluminie. Dopiero po usunięciu przyczyny i potwierdzeniu spójności wszystkich replik można uznać operację za zakończoną. Dokumentacja powinna zapisywać użyte kopie, kolejność dzienników, moment wykonania recovery oraz końcowy stan każdej repliki.