Wysyłanie dziennika (ang. log shipping) jest jedną z podstawowych technik ochrony i odzyskiwania danych po awarii (ang. distaster recovery, DR), jakie dostępne są w systemie SQL Server od kilkunastu lat. Niektóre źródła ukazują wysyłanie dziennika również jako prostą realizację wysokiej dostępności (ang. high availability, HA), jednak to, czy wysyłanie dziennika uznawać będziemy jako rozwiązanie DR czy HA, podyktowane jest głównie fizycznym położeniem naszych serwerów - jeśli funkcję Log shipping wykorzystywać będziemy lokalnie, możemy o niej wówczas mówić w kontekście wysokiej dostępności, natomiast dla serwerów rozstawionych od siebie w dużych odległościach narzędzie to przyjmować będzie formę rozwiązania DR. W obu tych przypadkach funkcja ta działa dokładnie tak samo, a jedyną różnicą jest tu zmiana charakteru rezerwowego serwera bazy danych. Serwer ten może więc odgrywać rolę serwera aktywnej kopii zapasowej, zdolnego do przejęcia pracy po serwerze głównym w przypadku jego awarii, serwera do odzyskiwania danych z innej lokalizacji lub serwera raportowania.
Proces wysyłania dziennika
Konfiguracja funkcji Log shipping polega na zdefiniowaniu obok głównego serwera produkcyjnego drugiego serwera, fizycznego lub wirtualnego, pełniącego funkcję zapasową. Taki serwer nie musi koniecznie być tak potężny, jak serwer główny, gdyż przez większość czasu nie będzie on wykonywał żadnej pracy, jednak w optymalnym przypadku obie te maszyny powinny dysponować zbliżoną mocą obliczeniową. Wysyłanie dziennika zbliżone jest pod względem działania do serwera aktywnej kopii zapasowej, dając nam możliwość automatycznego przywracania kopii zapasowej bazy danych na serwerze rezerwowym. Różnica pomiędzy tymi rozwiązaniami polega na tym, że wysyłanie dziennika umożliwia nam również automatyczne przesyłanie i przywracanie w ten sposób dzienników transakcji bazy danych, co nie tylko uwalnia nas od ręcznego wykonywania pracy, ale też minimalizuje ilość danych, jakie możemy utracić w przypadku awarii. Jeśli dziennik transakcji wysyłany jest na serwer rezerwowy co 15 minut, oznacza to, że w najgorszym przypadku utracimy dane wprowadzone do bazy nie dalej niż 15 minut temu.
Działanie funkcji wysyłania dziennika opiera się na funkcjonowaniu narzędzia SQL Agent i rozpoczyna się od utworzenia wstępnej migawki produkcyjnej bazy danych, która jest jej kompletną kopią zapasową. Od tej pory wszystkie operacje odnotowywane w dzienniku transakcyjnym tej bazy są okresowo wysyłane na drugi serwer, gdzie są one następnie odtwarzane w celu ciągłego utrzymywania zapasowej repliki bazy w aktualnym stanie. Należy zwrócić uwagę, że o ile proces tworzenia kopii zapasowej dziennika transakcji na serwerze podstawowym, jego kopiowanie na serwer rezerwowy i przywracanie na nim przysłanych transakcji następuje w pełni automatycznie, to w przypadku wystąpienia awarii serwera podstawowego funkcja ta nie dokonuje automatycznego przełączenia w tryb pracy awaryjnej.
Log shipping jest więc bardziej narzędziem do odzyskiwania danych po awarii, i nawet w takim kontekście jest to dość proste rozwiązanie. Jak już wspomnieliśmy, wysyłanie dziennika odbywa się okresowo, przez co kopia bazy danych przechowywana na serwerze zapasowym nigdy praktycznie nigdy nie jest aktualna. Tym samym w przypadku wystąpienia awarii zawsze dochodzi do utraty części danych - tych, które nie zostały przesłane od czasu ostatniej wysyłki dziennika.
W momencie wystąpienia awarii serwera głównego jesteśmy zmuszeni ręcznie dokonać przełączenia pracy na drugi serwer. Należy jednak podkreślić, że choć działanie samej bazy danych kontynuowane jest od tej pory na nowym serwerze zapasowym, to żaden z połączonych do tej pory z bazą użytkowników nie zostanie domyślnie przekierowany na ten drugi serwer. W większości przypadków administratorzy wykorzystują więc w tym celu proste obejście, polegające na konfigurowaniu maszyn klienckich do korzystania nie z konkretnych nazw lub adresów IP serwerów bazy danych, lecz do ich nazw kanonicznych, będących po prostu aliasami. Dzięki temu wszyscy klienci odwołują się do pewnego aliasu, który może być odtąd utożsamiany z dowolnym serwerem. W razie awarii wystarczy więc odpowiednio zmodyfikować rekord CNAME w konfiguracji DNS, tak by odnosił się do serwera zapasowego. Wadą tego rozwiązanie jest to, że klienci po pozyskaniu konfiguracji z serwera DNS przez około 10 minut przechowują ją w pamięci podręcznej, przez co po zmodyfikowaniu rekordu CNAME może minąć trochę czasu, zanim klienci ponownie pobiorą nową konfigurację z poprawnym adresem działającego serwera bazy danych. Oczywiście można zmodyfikować czas życia takiego rekordu, aby przechowywany był w pamięci podręcznej przez krótszy czas, jednak w przypadku dużej liczby klientów może to spowodować zauważalny wzrost ruchu sieciowego.
Funkcja wysyłania dziennika ma jeszcze jedną istotną zaletę. Jako że transakcje z dziennika przesyłane są na serwer zapasowy okresowo, istniejąca na tym serwerze kopia bazy danych aktualizowana jest z opóźnieniem. To dosyć duże niedociągnięcie, które w specyficznych przypadkach może nam się jednak przydać. Załóżmy, że przez przypadek usunęliśmy z bazy danych ważną tabelę, która istniała w tej bazie od dawna i jest dosyć ważnym komponentem naszego systemu. W normalnym przypadku w celu jej odzyskania musielibyśmy sięgnąć do kopii zapasowej tej bazy, co może zająć trochę czasu. Skoro jednak tabela ta z powodu wspomnianego opóźnienia nadal znajduje się na serwerze zapasowym, skąd w łatwy sposób możemy pozyskać ten dane i przywrócić je na serwerze głównym.
Funkcja wysyłania dziennika w starszych wydaniach systemu SQL Server wykorzystywana była jako jedno z podstawowych rozwiązań utrzymywania serwera rezerwowego w aktualnym stanie, zaś później zastępowana była funkcją dublowania bazy danych. W przeciwieństwie do funkcji dublowania bazy danych, gdzie tworzona jest wyłącznie jedna kopia bazy nazywana repliką (ang. mirrored database), wysyłanie dziennika pozwala na utworzenie jednej lub więcej kopii zapasowych bazy, które nazywane są po prostu bazami drugorzędnymi (ang. secondary database).
Wysyłanie dziennika jest również wykorzystywane w procesie dokonywania uaktualnienia typu side-by-side, w którym nowa wersja systemu SQL Server instaluje się obok istniejącego wydania, lub wdrażana jest bezpośrednio na nowym serwerze, i polega na migracji na ten serwer istniejącej bazy danych. Proces migracji można przeprowadzić na kilka różnych sposobów, z których jednym jest właśnie przywrócenie bazy danych z wykorzystaniem wysyłania dziennika.
Podobnie jak replikacja transakcyjna czy dublowanie danych, odzyskiwanie danych z wykorzystaniem wysyłania dziennika nie jest możliwe w przypadku stosowania prostego modelu odzyskiwania, jako że w modelu tym transakcje nie są utrwalane w ramach dziennika transakcji. Dozwolone są więc wyłącznie modele odzyskiwania Bulk Logged i Full.
Informacje i wszelkie obiekty dotyczące operacji wykonywanych w ramach funkcji wysyłania dziennika przechowywane są w systemowej bazie danych msdb.
Aby na serwerze drugorzędnym było możliwe przywrócenie transakcji odebranych przez agenta SQL Agent, zapasowa baza danych musi znajdować się w trybie odzyskiwania NORECOVERY (użytkownicy nie mają dostępu do bazy) lub STANDBY (użytkownicy mogą tylko odczytywać z bazy, ale tylko w czasie między kolejnymi operacjami przywracania).
Serwer monitorujący
Zaleca się, aby poza serwerem głównym i serwerem drugorzędnym w środowisku utworzony został jeszcze jeden serwer fizyczny, który monitorował będzie proces wysyłania i odbierania dziennika transakcji. Taki serwer nie jest wymagany, ale jego wdrożenie przyniesie nam wiele korzyści. Funkcję serwera monitorującego może pełnić dowolna edycja systemu SQL Server, wliczając w to również edycję Express. Gdy serwer ten bierze udział w operacji wysyłania dziennika, odnotowuje on i gromadzi informacje na ich temat w swojej bazie danych. Dzięki temu mamy szczegółową wiedzę na temat tego, kiedy dla dziennika transakcji została utworzona kopia zapasowa na serwerze głównym, kiedy została ona przywrócona na serwerze drugorzędnym, oraz ile czasu upłynęło pomiędzy tymi operacjami. W razie nie przekroczenia ustalonych przez administratora progów może on zostać automatycznie powiadomiony, co jest niezwykle przydatne, zwłaszcza że taki serwer może monitorować kilka środowisk na raz. Z oczywistych powodów serwer monitorujący powinien być zaimplementowany jako osobny serwer fizyczny lub serwer wirtualny ulokowany poza serwerami głównym i drugorzędnym.
