Usuwanie replik

Usuwanie replik z grupy dostępności wymaga wcześniejszego wyłączenia synchronizacji dla danej bazy.

Rola repliki w grupie dostępności SQL Server

Usuwanie repliki z grupy dostępności Always On w Microsoft SQL Server oznacza wycofanie jednej instancji uczestniczącej w ochronie określonych baz danych. Replika może pełnić rolę podstawową albo pomocniczą, a jej zadaniem jest utrzymywanie kopii baz oraz obsługa przełączenia awaryjnego, jeżeli konfiguracja na to pozwala. W środowisku z kilkoma replikami każda baza objęta grupą dostępności ma własny stan synchronizacji, dlatego usunięcie repliki nie jest zwykłym skasowaniem wpisu konfiguracyjnego.

Przed zmianą trzeba ustalić, która replika jest obecnie podstawowa, jakie bazy są do niej przypisane oraz czy usuwany węzeł obsługuje połączenia odczytowe, automatyczne przełączenia albo kopie zapasowe. Znaczenie ma również tryb dostępności. Replika synchroniczna może uczestniczyć w automatycznym przełączeniu, natomiast replika asynchroniczna zwykle służy do pracy z większym opóźnieniem i wymaga odrębnej oceny ryzyka utraty ostatnich zmian.

Wyłączenie synchronizacji dla danej bazy jest etapem przygotowawczym. Po odłączeniu bazy od mechanizmu HADR jej kopia na usuwanej replice przestaje być utrzymywana jako część grupy dostępności. Sama baza może nadal pozostać na instancji SQL Server, ale jej dalsze użycie, usunięcie albo zmiana trybu pracy wymagają osobnej decyzji administracyjnej.

Przebieg kontrolowanego wycofania repliki

Najpierw warto wykonać inwentaryzację konfiguracji i sprawdzić bieżący stan baz na wszystkich replikach. Należy potwierdzić, że nie trwa synchronizacja początkowa, ponowne dołączanie bazy, przełączenie ról ani operacja przywracania. Trzeba też sprawdzić, czy usuwana replika nie jest jedyną kopią używaną do odczytów, raportowania lub wykonywania kopii zapasowych.

W SQL Server wycofanie repliki przeprowadza się z poziomu konfiguracji grupy dostępności, wskazując nazwę grupy oraz nazwę instancji uczestniczącej w tej grupie. Operację wykonuje się na replice podstawowej, ponieważ to ona zarządza definicją grupy. Wcześniej bazy powinny zostać odłączone od synchronizacji zgodnie z zaplanowaną procedurą. Wykonanie tylko jednej części operacji może pozostawić niespójny stan administracyjny albo wywołać błędy podczas późniejszych prób ponownego dołączenia.

Jeżeli usuwana replika przechowuje lokalne kopie baz, po zmianie konfiguracji trzeba zdecydować, czy zostawić je jako niezależne bazy, czy usunąć je po dodatkowym potwierdzeniu. Odłączenie bazy od grupy nie jest równoznaczne z bezpiecznym skasowaniem plików danych i logu transakcyjnego. Przed usunięciem należy sprawdzić zależności aplikacji, zadania SQL Server Agent, harmonogramy kopii zapasowych oraz ewentualne procedury monitorujące.

Inaczej wygląda usuwanie całej repliki, a inaczej usuwanie pojedynczej bazy z grupy. W pierwszym przypadku zmieniana jest lista uczestników grupy dostępności. W drugim przypadku replika nadal może obsługiwać pozostałe bazy, lecz wskazana baza przestaje być częścią ochrony Always On. Te operacje nie powinny być traktowane zamiennie, ponieważ mają inny wpływ na przełączenia, routing odczytów i monitoring.

Po zakończeniu należy zweryfikować, czy grupa zawiera wyłącznie oczekiwane repliki, czy wszystkie pozostałe bazy mają prawidłowy stan synchronizacji oraz czy aplikacje nie próbują łączyć się z wycofaną instancją. Warto również sprawdzić konfigurację listenera, reguły routingu tylko do odczytu i alerty monitorujące dostępność poszczególnych kopii.

Co zwykle komplikuje tę operację

Jednym z częstszych problemów jest próba usunięcia repliki, gdy administrator nie rozróżnia stanu grupy od stanu konkretnej bazy. Grupa może być dostępna, ale pojedyncza baza może mieć opóźnioną synchronizację, zawieszony transport logu albo status wymagający ponownego uruchomienia synchronizacji. W takiej sytuacji sama zmiana konfiguracji nie rozwiązuje przyczyny problemu i może utrudnić późniejsze odtworzenie kopii.

Ryzyko rośnie, gdy usuwana replika była wykorzystywana do automatycznych kopii zapasowych. SQL Server pozwala kierować część zadań backupu do preferowanej repliki, dlatego po jej wycofaniu trzeba sprawdzić, gdzie będą wykonywane kopie oraz czy nie zmieni się obciążenie pozostałych instancji. Podobnej kontroli wymagają zadania raportowe i aplikacje korzystające z adresu listenera.

Osobnego sprawdzenia wymaga scenariusz, w którym replika podstawowa ma zostać wycofana. Wtedy należy zaplanować zmianę roli, ocenić możliwość kontrolowanego przełączenia i potwierdzić, że aplikacje rozpoznają nową replikę podstawową. Nie powinno się usuwać aktywnej repliki podstawowej bez ustalenia, gdzie będzie kontynuowana obsługa zapisów.

Problemy mogą wynikać także z pozostałości po starej konfiguracji: nieaktualnych nazw instancji, wpisów w dokumentacji, zadań agenta, aliasów sieciowych albo skryptów monitorujących. Po fizycznym wycofaniu repliki system może działać poprawnie, a mimo to generować błędy, ponieważ narzędzie nadzorcze nadal oczekuje odpowiedzi od usuniętego uczestnika.

Przed wykonaniem zmiany często pojawia się pytanie, czy wyłączenie synchronizacji usuwa dane. Nie musi tak być. Zmienia ono relację bazy z grupą dostępności, natomiast pliki pozostają na dysku do czasu osobnego działania. Inną kwestią jest możliwość ponownego dodania repliki. Zależy ona między innymi od zachowania zgodności wersji SQL Server, przygotowania kopii bazy i logu oraz spełnienia wymagań konfiguracji grupy.

Moment na konsultację i zabezpieczenie danych

Do administratora baz danych warto zgłosić się przed operacją, jeżeli nie ma pewności, która replika jest podstawowa, jakie bazy są objęte grupą albo czy usuwany uczestnik realizuje kopie zapasowe. Konsultacja jest szczególnie potrzebna przy bazach obsługujących zapisy produkcyjne, gdy planowana zmiana może wpłynąć na ciągłość pracy aplikacji.

Pomoc specjalisty jest wskazana także wtedy, gdy synchronizacja jest opóźniona, występują błędy transportu logu, baza ma status niedostępnej lub grupa nie przechodzi poprawnie testów przełączenia. W takich przypadkach najpierw trzeba ustalić stan danych i przyczynę nieprawidłowości, a dopiero potem wybierać sposób odłączenia repliki.

Przed zmianą należy potwierdzić aktualność kopii zapasowych, możliwość odtworzenia bazy oraz dostępność planu powrotu do poprzedniej konfiguracji. Dokumentacja powinna zawierać listę baz, role replik, zależności aplikacyjne, zadania backupu i sposób weryfikacji po operacji. Samo usunięcie wpisu z grupy nie kończy prac administracyjnych, jeżeli pozostały zależne zadania lub nieaktualne punkty połączeń.

Jeżeli problem dotyczy fizycznego komputera, dysku, pamięci lub innego podzespołu, Warszawskie Pogotowie Komputerowe wykonuje diagnostykę i naprawę sprzętu komputerowego oraz podstawowy odzysk danych z uszkodzonych nośników. W przypadku konfiguracji grupy dostępności decyzje dotyczące ról, synchronizacji i integralności baz powinny jednak zostać poprzedzone analizą osoby odpowiedzialnej za Microsoft SQL Server.