Mirroring bazy danych (Database Mirroring – przestarzałe)

Database Mirroring to mechanizm utrzymywania kopii bazy na drugim serwerze, obecnie oznaczony jako przestarzały.

Rola mirroringu w architekturze SQL Server

Database Mirroring, czyli mirroring bazy danych, był mechanizmem wysokiej dostępności przeznaczonym dla Microsoft SQL Server. Jego zadaniem było utrzymywanie drugiej kopii konkretnej bazy danych na odrębnej instancji SQL Server. Instancja podstawowa była określana jako principal, natomiast instancja przechowująca kopię jako mirror. Obie instancje komunikowały się przez specjalnie skonfigurowany punkt końcowy mirroringu, wykorzystujący protokół TCP.

Mechanizm działał na poziomie pojedynczej bazy danych, a nie całej instancji. Oznaczało to, że każdą bazę przeznaczoną do ochrony trzeba było skonfigurować osobno. Mirroring nie tworzył ogólnej repliki wszystkich baz systemowych, ustawień instancji, loginów, zadań SQL Server Agent ani konfiguracji serwera. Po przełączeniu na kopię zapasową część zależności infrastrukturalnych nadal wymagała odtworzenia lub ręcznej konfiguracji.

Mirror nie był zwykłą kopią plików bazy. Principal przesyłał rekordy dziennika transakcji do instancji mirror, gdzie były one zapisywane i odtwarzane w odpowiedniej kolejności. Dzięki temu kopia mogła pozostawać aktualna bez cyklicznego kopiowania całego pliku danych. Warunkiem działania była prawidłowa konfiguracja punktów końcowych, zgodność uprawnień oraz możliwość komunikacji między obiema instancjami.

Tryby pracy i warunki przełączenia

Database Mirroring obsługiwał tryb high-safety, w którym principal oczekiwał na potwierdzenie zapisu dziennika po stronie mirror. Był to tryb synchroniczny, ograniczający możliwość utraty zatwierdzonych transakcji, ale zwiększający zależność czasu operacji od opóźnień sieciowych i wydajności drugiej instancji. W trybie high-safety możliwe było automatyczne przełączenie, jeżeli w konfiguracji uczestniczył witness i spełnione były wymagania dotyczące stanu sesji.

Tryb high-performance działał asynchronicznie. Principal nie musiał czekać na pełne przetworzenie przesyłanego dziennika przez mirror, dlatego rozwiązanie lepiej tolerowało większe opóźnienia sieci. W zamian pojawiała się możliwość utraty części ostatnich transakcji, jeżeli principal uległ awarii przed dostarczeniem i zastosowaniem odpowiednich rekordów dziennika na mirror. Ten tryb nie zapewniał automatycznego failoveru charakterystycznego dla synchronicznej konfiguracji z witness.

Witness nie przechowywał trzeciej kopii danych. Jego rolą było uczestniczenie w ustalaniu, czy principal jest dostępny oraz czy można bezpiecznie rozpocząć automatyczne przełączenie. Zastosowanie witnessa miało ograniczać ryzyko, że obie instancje uznają się jednocześnie za aktywne. Takie rozdzielenie decyzji było istotne dla uniknięcia sytuacji określanej jako split brain.

Konfiguracja sesji i ograniczenia mechanizmu

Przygotowanie mirroringu wymagało wykonania pełnej kopii zapasowej bazy na principal oraz kopii dziennika transakcji, a następnie odtworzenia ich na mirrorze w stanie umożliwiającym zastosowanie kolejnych rekordów logu. Dopiero po przygotowaniu bazy można było ustanowić sesję partnerów. Konfiguracja obejmowała między innymi utworzenie punktów końcowych, przyznanie dostępu do nich oraz wskazanie adresów partnera i ewentualnego witnessa.

Sesję można było kontrolować poleceniami języka Transact-SQL, takimi jak ALTER DATABASE ... SET PARTNER, ALTER DATABASE ... SET WITNESS oraz ALTER DATABASE ... SET PARTNER FAILOVER. Ostatnie z tych działań służyło do kontrolowanego, ręcznego przełączenia ról, gdy baza działała w stanie pozwalającym na bezpieczny failover. Przełączenie awaryjne nie było tym samym co odtworzenie bazy z kopii zapasowej: zmieniało role uczestników aktywnej sesji mirroringu.

Mirroring miał istotne ograniczenia projektowe. Jedna baza mogła mieć jednego partnera mirror, więc mechanizm nie zapewniał wielu równoległych kopii dostępnych dla odczytu. Mirror nie był przeznaczony do obsługi zapytań użytkowników jako zwykła replika raportowa. Nie zastępował także kopii zapasowych, ponieważ awaria lub logiczne usunięcie danych na principal mogły zostać odzwierciedlone na mirrorze. Monitorowanie wymagało obserwacji stanu sesji, opóźnienia przesyłania logu oraz ewentualnych przerw w komunikacji.

Dlaczego Database Mirroring jest technologią przestarzałą

Microsoft oznaczył Database Mirroring jako mechanizm przestarzały i wskazał nowsze rozwiązania do ochrony baz SQL Server. W praktyce oznacza to, że mirroring nie powinien być pierwszym wyborem przy projektowaniu nowej infrastruktury. Istniejąca konfiguracja może nadal wymagać analizy podczas migracji lub usuwania awarii, ale jej dalsze rozwijanie zwiększa zależność od rozwiązania, którego cykl rozwoju został zakończony.

Najważniejszym kierunkiem zastępczym są grupy dostępności Always On Availability Groups, zapewniające ochronę zestawu baz oraz możliwość pracy z wieloma replikami, zależnie od używanej edycji i wersji SQL Server. W innych scenariuszach stosuje się także log shipping, replikację lub regularne kopie zapasowe, jednak każde z tych rozwiązań ma inną funkcję i inne wymagania. Dobór następcy wymaga ustalenia oczekiwanego czasu odtworzenia, dopuszczalnej utraty danych, sposobu przełączania oraz zależności aplikacji od nazwy serwera i bazy.

Podczas diagnozowania starej konfiguracji należy rozdzielić problem samego mechanizmu od problemów środowiskowych. Warto sprawdzić stan principal i mirror, dostępność punktów końcowych, błędy w dzienniku SQL Server, opóźnienie przesyłania logu, stan synchronizacji oraz ostatnie kopie zapasowe. Należy również zweryfikować, czy aplikacja korzysta z aktualnej roli po przełączeniu. Sama obecność drugiej kopii bazy nie oznacza jeszcze poprawnie działającej ochrony: sesja może być zawieszona, niesynchronizowana albo pozbawiona warunków automatycznego failoveru.