Dublowanie bazy danych (ang. database mirroring) jest jedną z podstawowych strategii realizacji wysokiej dostępności w środowisku wykorzystującym system SQL Server. Należy jednak zaznaczyć, że funkcja ta, wprowadzona po raz pierwszy w wersji SQL Server 2005, w kolejnych wydaniach tego produktu wypierana była stopniowo przez tzw. grupy dostępności AlwaysOn (ang. AlwaysOn Availability Groups), zaś od wersji SQL Server 2016 rozwiązanie to nie jest już dłużej dostępne. Mimo wszystko uważamy, że funkcja dublowania baz danych nadal jest warta poznania, jako że w większości środowisk produkcyjnych będzie ona stosowana jeszcze przez wiele lat, zaś jej zgłębienie ułatwi nam zrozumienie różnic występujących pomiędzy nią a wspomnianą technologią będącą jej bezpośrednim następcą.
Proces dublowania bazy danych polega na wstępnym utworzeniu, a następnie ciągłym utrzymywaniu zawsze aktualnej kopii bazy danych, która przechowywana jest w ramach odrębnej instancji serwera SQL Server. Aby na wypadek awarii hosta uchronić się przed potencjalną utratą obu tych baz jednocześnie, tj. bazy źródłowej i jej kopii, sporządzona w ten sposób kopia bazy danych powinna być przechowywana na odrębnym serwerze fizycznym.
Po ustanowieniu sesji dublowania pomiędzy bazą oryginalną a jej kopią, klienci komunikują się z bazą na serwerze podstawowym (ang. principal server) w standardowy sposób. Różnica w tym wypadku polega na tym, że wszystkie wykonywane na bazie operacje są następnie odtwarzane na sparowanej bazie danych zlokalizowanej w osobnej instancji, zgodnie z ich kolejnością zapisu w dzienniku transakcji.
W zależności od sposobu konfiguracji funkcji dublowania bazy danych, bazy dublowana może działać w trybie podwyższonego bezpieczeństwa (ang. high-safety mode) lub podwyższonej wydajności (high-performance mode). Różnica pomiędzy tymi trybami polega przede wszystkim na sposobie zatwierdzania transakcji w obrębie sesji dublowania. Innymi słowy, w trybie wysokiej wydajności podstawowa instancja bazy nie czeka na potwierdzenie otrzymania rekordu dziennika przez bazę w drugiej instancji, a tym samym obie bazy zatwierdzają realizowane transakcje niezależnie od siebie. Jako że w takim przypadku obie bazy mogą potencjalnie przechowywać różny poziom informacji, w razie awarii pierwotnej bazy danych i przejściu w tryb pracy awaryjnej może dojść do utraty części informacji, które do momentu przełączenia nie zdążyły zostać zatwierdzone w drugiej bazie.
Z kolei w trybie podwyższonego bezpieczeństwa nigdy nie mamy do czynienia z utratą takich danych, gdyż transakcje są zawsze zatwierdzane w obu bazach danych po ch uprzednim zsynchronizowaniu. Inaczej mówiąc, dublowana baza danych będzie dokonywać zatwierdzeń rekordów dziennika transakcji dopiero po uzyskaniu potwierdzenia odnotowania tego rekordu w drugiej instancji. Gdy obie bazy mają już wiedzę o danym rekordzie do zatwierdzenia, zostaje on jednocześnie zapisany w bazie po obu stronach. Ten sposób pracy co prawda chroni nas przed utratą danych, jednak z powodu wymaganych potwierdzeń synchronizujących obie instancje bazy spowalnia wykonywanie transakcji. Tryb ten ma jeszcze jedną zaletę. Otóż jeśli w ramach takiej konfiguracji zdefiniowaliśmy sobie dodatkowy serwer nazywany formalnie monitorem (ang. witness), wówczas pozwoli nam on skorzystać z dobrodziejstw automatycznego przełączania w tryb pracy awaryjnej.
Funkcja dublowania bazy danych na pierwszy rzut wydaje się mieć wiele zalet, jednak nie jest ona niestety rozwiązaniem idealnym; z resztą gdyby była, nie doczekałaby się tak szybkiego wyparcia przez inną technologię. Co prawda możemy dzięki niej dublować wybrane lub nawet wszystkie bazy danych zlokalizowane w określonej instancji, jednak dublowane mogą być wyłącznie bazy danych wykorzystujące pełny model odzyskiwania. Należy też pamiętać, że w ramach dublowania bazy danych każda baza może zostać sparowana tylko z jedną kopią. Tym samym utworzenie dla podstawowej bazy drugiego duplikatu nie jest możliwe, a co za tym idzie dublowanie bazy danych nie należy do wysoce skalowalnych rozwiązań.
Wymagania wstępne i ograniczenia
Podobnie jak każda zaawansowana funkcja, dublowanie bazy danych do swojego poprawnego działania wymaga uprzednio odpowiedniego przygotowania środowiska. Pierwszym koniecznym do spełnienia warunkiem jest posiadanie takich samych wersji i edycji systemu SQL Server po obu stronach sesji dublowania. Ograniczenie to jest nieco mniej restrykcyjne w stosunku do serwera monitorującego, który może pracować pod kontrolą dowolnej edycji systemu SQL Server, która wspiera to rozwiązanie. Z uwagi na obowiązujący podział funkcjonalności w obrębie istniejących edycji systemu SQL Server, funkcję monitora może w praktyce pełnić dowolna edycja systemu SQL Server, wliczając w to również edycje Web i Express. Niestety te okrojone z funkcjonalności edycje nie są w stanie odgrywać pozostałych ról dostępnych w sesji dublowania, więc nadają się one wyłącznie jako podstawa dla serwera monitorującego. Edycje Standard i Business Intelligence poza monitorowaniem obsługują monitorowanie w trybie podwyższonego bezpieczeństwa, zaś edycja Enterprise - z uwagi na bogactwo swojej funkcjonalności - obsługuje wszystkie dostępne tryby pracy w ramach sesji dublowania.
Wśród pozostałych ograniczeń funkcji dublowania bazy danych warto także wymienić możliwość dublowania wyłącznie baz danych zdefiniowanych przez użytkownika, co oznacza, że tworzenie duplikatów dla baz master, model, tempdb czy msdb nie jest możliwe. Sparowanym bazom nie możemy także nadawać nowych nazw, zaś wszelkie rozproszone w ich obrębie transakcje nie są obsługiwane. Ponadto jeśli na bazie danych zdefiniowaliśmy grupę plików FILESTREAM, nie będzie ona mogła zostać zdublowana i odwrotnie, tzn. na serwerze podstawowym biorącym udział w dublowaniu nie można takiej grupy zdefiniować.
W przypadku korzystania z serwera monitorującego z włączoną obsługą automatycznego przełączania w tryb pracy awaryjnej, należy zadbać o niskie zużycie zasobów procesora na serwerach podstawowym i dublowanym, gdyż zbyt duże ich obciążenie możne skutkować zbyt długim czasem odpowiedzi do serwera monitorującego, co może doprowadzić do niepożądanego przełączenia w tryb pracy awaryjnej.
341f31d.png)