SQL Server Log Shipping

Log Shipping to mechanizm cyklicznego przesyłania i odtwarzania kopii dziennika na serwerze zapasowym.

Na czym polega SQL Server Log Shipping

SQL Server Log Shipping jest mechanizmem wysokiej dostępności i odtwarzania awaryjnego w Microsoft SQL Server. Działa poprzez cykliczne wykonywanie kopii zapasowych dziennika transakcji bazy na serwerze podstawowym, kopiowanie tych plików na jeden lub większą liczbę serwerów pomocniczych oraz ich regularne odtwarzanie w pomocniczej bazie danych. Każdy etap jest wykonywany przez zadania SQL Server Agent, dlatego poprawna praca agenta na odpowiednich instancjach jest jednym z warunków działania konfiguracji.

Log Shipping nie przesyła pojedynczych zmian w czasie rzeczywistym. Najpierw powstaje plik kopii dziennika, następnie plik musi zostać skopiowany, a dopiero później odtworzony na serwerze zapasowym. Opóźnienie zależy między innymi od częstotliwości wykonywania kopii, szybkości transferu plików, obciążenia dysków i czasu potrzebnego na operację RESTORE LOG. Mechanizm może ograniczyć utratę danych po awarii, ale nie gwarantuje punktu odtworzenia późniejszego niż ostatnia poprawnie wykonana i odtworzona kopia dziennika.

Warunki konfiguracji i elementy środowiska

Baza uczestnicząca w Log Shipping musi korzystać z modelu odzyskiwania FULL albo BULK_LOGGED. W modelu SIMPLE kopie dziennika transakcji nie mogą być wykonywane, ponieważ SQL Server automatycznie zarządza obcinaniem dziennika bez zachowania pełnego łańcucha kopii wymaganych do odtwarzania. Przed uruchomieniem konfiguracji należy wykonać pełną kopię zapasową bazy, a następnie zainicjalizować bazę pomocniczą z użyciem tej kopii lub przygotować ją inną metodą zachowującą zgodność łańcucha dziennika.

Konfiguracja obejmuje bazę podstawową, bazę pomocniczą oraz opcjonalny serwer monitorujący. Na serwerze podstawowym działa zadanie tworzące kopie dziennika. Zadanie kopiowania przenosi pliki do wskazanego katalogu na serwerze pomocniczym, a zadanie odtwarzania wykonuje je w kolejności wynikającej z numerów sekwencyjnych kopii. SQL Server przechowuje informacje o stanie operacji i opóźnieniach w bazie systemowej msdb. Do konfiguracji można użyć kreatora właściwości bazy w SQL Server Management Studio albo procedur składowanych Log Shipping, takich jak sp_add_log_shipping_primary_database i procedury dotyczące dodawania bazy pomocniczej.

Podczas odtwarzania baza pomocnicza może pozostawać w stanie NORECOVERY, w którym nie jest dostępna dla użytkowników, albo w stanie STANDBY. Tryb STANDBY pozwala na dostęp tylko do odczytu pomiędzy kolejnymi operacjami odtwarzania, lecz każde następne odtworzenie może wymagać rozłączenia użytkowników korzystających z tej bazy. Przy planowaniu ścieżek plików należy uwzględnić, czy lokalizacje plików danych i dziennika są takie same na obu instancjach; w przeciwnym razie trzeba prawidłowo określić mapowanie plików podczas odtwarzania.

Przebieg operacji i kontrola opóźnień

Typowy cykl rozpoczyna się od wykonania polecenia BACKUP LOG na bazie podstawowej. Utworzony plik zawiera fragment dziennika należący do określonego łańcucha kopii. Następnie zadanie kopiowania przenosi plik do katalogu docelowego, a zadanie odtwarzania wykonuje polecenie RESTORE LOG na bazie pomocniczej. Kopie muszą być odtwarzane w prawidłowej kolejności; pominięcie wymaganej kopii albo uszkodzenie pliku zatrzymuje dalsze odtwarzanie do czasu usunięcia problemu.

SQL Server Agent zapisuje historię uruchomień zadań, a konfiguracja Log Shipping pozwala definiować progi alarmowe dla czasu od ostatniej kopii dziennika, czasu ostatniego skopiowania pliku i czasu ostatniego odtworzenia. Przekroczenie progu nie oznacza samo w sobie utraty danych, ale wskazuje, że bieżące opóźnienie odbiega od założonego harmonogramu. Diagnostyka powinna obejmować historię zadań agenta, dostępność katalogów, uprawnienia kont usług, wolne miejsce na dyskach, łączność między serwerami oraz komunikaty z dziennika SQL Server.

Istotne jest rozróżnienie czasu utworzenia kopii od czasu jej odtworzenia. Serwer pomocniczy może mieć poprawnie skopiowane pliki, ale nadal pozostawać opóźniony, jeśli zadanie RESTORE LOG nie działa. Podobnie wykonanie kopii na serwerze podstawowym nie zapewnia jej ochrony, jeżeli plik nie został zapisany w dostępnej lokalizacji albo nie dotarł do serwera zapasowego. Regularnie należy także testować możliwość odtworzenia bazy oraz sprawdzać, czy procedury ręcznego przełączenia uwzględniają najnowszą dostępną kopię dziennika.

Przełączenie awaryjne i ograniczenia rozwiązania

SQL Server Log Shipping nie wykonuje automatycznego przełączenia awaryjnego i nie zapewnia automatycznej synchronizacji ról. Po awarii serwera podstawowego administrator musi ustalić, jaka jest ostatnia dostępna poprawna kopia dziennika, odtworzyć ją na serwerze pomocniczym, a następnie zakończyć sekwencję operacją odzyskania bazy, na przykład RESTORE DATABASE ... WITH RECOVERY. Po wykonaniu WITH RECOVERY baza pomocnicza staje się bazą użytkową, ale nie można już bezpośrednio kontynuować tej samej sekwencji odtwarzania kolejnych kopii dziennika.

Po przełączeniu trzeba skierować aplikacje do nowego serwera, zweryfikować logowania, uprawnienia i zależności aplikacyjne oraz ustalić sposób odtworzenia pierwotnej konfiguracji. Log Shipping replikuje zawartość bazy przez kopie dziennika, lecz nie przenosi automatycznie wszystkich obiektów znajdujących się poza bazą. Osobno należy uwzględnić między innymi zadania SQL Server Agent, logowania instancji, konfigurację połączeń, certyfikaty, urządzenia kopii zapasowych i elementy aplikacji zależne od konkretnego serwera.

Mechanizm jest przeznaczony przede wszystkim do utrzymywania kopii bazy na innym serwerze i przygotowania kontrolowanego odtworzenia po awarii. Nie zastępuje regularnych kopii pełnych, różnicowych i dziennika ani testów odtwarzania. W przypadku problemów z SQL Server warto sprawdzić stan łańcucha kopii, historię zadań SQL Server Agent, komunikaty operacji BACKUP i RESTORE oraz zgodność harmonogramów. Diagnostyka infrastruktury komputerowej powinna dodatkowo obejmować dyski, pamięć, sieć i stabilność systemu, ponieważ awaria któregoś z tych elementów może przerwać wykonywanie lub kopiowanie plików dziennika.