Mirroring (przestarzała technologia)

Mirroring to wycofana technologia wysokiej dostępności SQL Server, zastąpiona grupami dostępności Always On.

Mirroring w SQL Server: mechanizm i zakres działania

Mirroring, określane w dokumentacji Microsoft jako database mirroring, było mechanizmem wysokiej dostępności przeznaczonym dla pojedynczej bazy danych w Microsoft SQL Server. Uczestniczą w nim dwa wystąpienia SQL Server: principal, czyli serwer główny, oraz mirror, czyli serwer lustrzany. Principal przyjmuje operacje zapisu, a mirror odtwarza przesyłany dziennik transakcji i utrzymuje własną kopię tej samej bazy. Mechanizm działa na poziomie bazy danych, a nie całej instancji, dlatego osobno trzeba było konfigurować każdą bazę objętą ochroną.

Mirroring nie jest zwykłym kopiowaniem plików MDF i LDF ani replikacją pojedynczych tabel. SQL Server przesyła rekordy dziennika transakcji przez zabezpieczone punkty końcowe mirroringu, a instancja mirror odtwarza je w swojej bazie. Przygotowanie kopii wymagało odtworzenia pełnej kopii zapasowej bazy oraz kolejnych kopii dziennika z opcją WITH NORECOVERY, aby baza docelowa pozostała w stanie oczekiwania na następne rekordy dziennika. Dopiero po poprawnym sparowaniu partnerów mogła rozpocząć się ciągła synchronizacja.

Tryby synchronizacji, witness i przełączanie ról

SQL Server database mirroring oferował tryb high-safety z synchronicznym przesyłaniem i zatwierdzaniem transakcji oraz tryb high-performance z asynchronicznym przesyłaniem. W trybie synchronicznym principal czekał na potwierdzenie zapisania odpowiednich informacji na mirrorze, co ograniczało możliwość utraty zatwierdzonych transakcji, ale mogło zwiększać czas odpowiedzi podczas opóźnień sieci lub obciążenia serwera. Tryb asynchroniczny pozwalał principalowi działać bez oczekiwania na każdą odpowiedź, lecz w chwili awarii mogła pozostać kolejka nieprzesłanych rekordów dziennika.

Opcjonalny witness był trzecim wystąpieniem SQL Server, które obserwowało stan partnerów i uczestniczyło w podejmowaniu decyzji o automatycznym przełączeniu. Automatyczny failover wymagał trybu high-safety oraz poprawnie działającego witnessa; sam mirror nie mógł bez dodatkowego głosu jednoznacznie rozstrzygnąć, czy principal rzeczywiście uległ awarii, czy tylko utracił łączność. Oprócz automatycznego przełączenia dostępne były przełączenie ręczne po zsynchronizowaniu baz oraz forced service, używane w określonych sytuacjach awaryjnych, gdy dopuszczalne było ryzyko utraty nieprzesłanych danych.

Ograniczenia starej technologii i następca Always On

Mirroring chronił konkretną bazę, ale nie zapewniał tak szerokiego modelu ochrony jak rozwiązania obejmujące wiele baz i cały klaster. Nie tworzył jednej wspólnej grupy dla zależnych baz aplikacji, nie przełączał automatycznie wszystkich baz systemowych i nie zapewniał ogólnego mechanizmu równoważenia odczytów. Baza mirror pozostawała zasadniczo niedostępna dla normalnych operacji użytkowników. W niektórych scenariuszach można było korzystać z migawki bazy mirror do odczytu, lecz migawka była osobnym, statycznym obrazem i nie zastępowała pełnego dostępu do aktualizowanej bazy.

Microsoft oznaczył database mirroring jako funkcję przestarzałą i wskazał Always On availability groups jako technologię zastępczą. Grupy dostępności Always On, wprowadzone w SQL Server 2012, pozwalają organizować wiele baz w grupy dostępności, utrzymywać repliki oraz definiować tryb synchroniczny lub asynchroniczny zależnie od topologii. Oznacza to, że w nowym projekcie nie powinno się rozpoczynać konfiguracji od mirroringu tylko dlatego, że starsza dokumentacja opisuje go jako prosty sposób wysokiej dostępności. Przy utrzymywaniu istniejącej instalacji trzeba natomiast sprawdzić wersję SQL Server, stan partnerów, opóźnienie dziennika, konfigurację endpointów i plan migracji do wspieranego rozwiązania.

Ślady mirroringu przy analizie awarii SQL Server

Podczas diagnostyki starego środowiska warto rozpocząć od właściwości mirroringu konkretnej bazy, jej roli, stanu synchronizacji i wartości liczników zaległego dziennika. Istotne są między innymi role principal i mirror, stany synchronized, synchronizing, disconnected lub suspended oraz informacja, czy ostatnia zmiana roli była ręczna, automatyczna czy wymuszona. Sam fakt, że druga instancja działa, nie potwierdza poprawności ochrony: mirror może nie otrzymywać nowych rekordów dziennika, endpoint może być zatrzymany, a synchronizacja może być zawieszona.

Analiza powinna obejmować także dzienniki SQL Server i system operacyjny, rozwiązywanie nazw hostów, dostępność portów używanych przez endpointy oraz zgodność certyfikatów lub kont usług stosowanych do uwierzytelniania połączeń. Po nieplanowanym przełączeniu należy potwierdzić, który serwer jest aktualnie principalem, gdzie kierują się połączenia aplikacji i czy pozostała instancja nie próbuje nadal pełnić starej roli. W przypadku komputera wykorzystywanego jako klient SQL Server objawy mogą obejmować niedostępność aplikacji, błędy połączeń albo pracę na nieaktualnym adresie. Naprawa wymaga wtedy rozdzielenia problemu stacji roboczej od problemu konfiguracji samego silnika bazy danych i odtworzenia prawidłowej ścieżki połączenia.