Failover forced

Failover forced to wymuszone przełączenie awaryjne, akceptujące ryzyko utraty niezreplikowanych jeszcze danych.

Na czym polega wymuszone przełączenie awaryjne

Failover forced oznacza wymuszenie przełączenia usługi, zasobu albo roli systemowej z aktualnie używanego węzła na inny węzeł, mimo że system nie potwierdził pełnej synchronizacji danych. W zwykłym przełączeniu awaryjnym mechanizm najpierw sprawdza dostępność węzła zapasowego, stan replikacji oraz możliwość bezpiecznego przekazania roli. Wymuszenie pomija część tych zabezpieczeń, ponieważ podstawowy węzeł może być niedostępny, odłączony od sieci albo niezdolny do zakończenia synchronizacji.

Najważniejszą konsekwencją jest możliwość utraty zmian, które zostały zapisane na aktywnym węźle, lecz nie dotarły jeszcze do węzła przejmującego usługę. Nie musi dojść do utraty całej bazy danych ani całego systemu plików. Ryzyko dotyczy przede wszystkim ostatnich operacji wykonanych przed awarią, buforów zapisu oraz transakcji pozostających w trakcie replikacji. Zakres utraty zależy od architektury rozwiązania, opóźnienia replikacji, sposobu potwierdzania zapisu i chwili, w której wykonano przełączenie.

Różnica między bezpiecznym a wymuszonym failoverem

W przełączeniu kontrolowanym aktywny węzeł przekazuje rolę po zamknięciu lub zatrzymaniu obsługiwanych procesów. System może opróżnić bufory, zatwierdzić oczekujące operacje, wysłać brakujące dane do repliki i dopiero wtedy uruchomić usługę w nowej lokalizacji. Taki przebieg ogranicza ryzyko niespójności, ale wymaga działającego połączenia z dotychczas aktywnym węzłem albo przynajmniej wiarygodnego potwierdzenia jego stanu.

Failover forced stosuje się wtedy, gdy oczekiwanie na potwierdzenie nie jest możliwe lub zagraża dostępności usługi. Przykładem może być trwała awaria zasilania, uszkodzenie kontrolera, niedostępność sieci między lokalizacjami albo zawieszenie systemu, który nadal posiada rolę aktywną, lecz nie odpowiada na polecenia. W takiej sytuacji administrator musi ocenić, czy ważniejsze jest szybkie przywrócenie działania, czy zachowanie maksymalnej kompletności najnowszych danych. Wymuszenie przełączenia jest decyzją operacyjną obciążoną ryzykiem, a nie metodą naprawy samej przyczyny awarii.

Ryzyko podwójnej aktywności i niespójności danych

Przed wymuszonym przełączeniem trzeba ustalić, czy poprzedni węzeł rzeczywiście przestał obsługiwać klientów. Jeżeli stary węzeł nadal przyjmuje zapisy, a nowy węzeł również zostanie uruchomiony jako aktywny, może powstać sytuacja określana jako split-brain, czyli jednoczesna aktywność dwóch stron systemu. Każda z nich może utworzyć własny zestaw zmian, a późniejsze połączenie danych może wymagać rozstrzygania konfliktów albo odtworzenia jednego ze stanów z kopii zapasowej.

Po przełączeniu należy sprawdzić nie tylko dostępność usługi, ale także logiczną spójność danych. Weryfikacja może obejmować liczbę i stan transakcji, kolejność zdarzeń, integralność indeksów, możliwość odczytu ostatnich rekordów oraz działanie operacji zapisu. Sam fakt, że aplikacja odpowiada na połączenia, nie dowodzi, że wszystkie dane zostały zachowane. W systemach z replikacją asynchroniczną szczególne znaczenie ma ustalenie ostatniego potwierdzonego punktu synchronizacji i porównanie go z informacjami z dzienników aktywnego węzła.

Postępowanie po wymuszonym przełączeniu awaryjnym

Po odzyskaniu podstawowego węzła nie powinno się od razu przywracać mu roli aktywnej. Najpierw trzeba zabezpieczyć logi, ustalić moment awarii, określić zakres niezsynchronizowanych zmian i wykluczyć równoległą pracę dwóch instancji. W zależności od użytej technologii konieczne może być ponowne zbudowanie repliki, wykonanie synchronizacji od pełnej kopii, odtworzenie dzienników transakcyjnych albo ręczne sprawdzenie operacji wykonanych tuż przed awarią.

Dokumentacja zdarzenia powinna wskazywać przyczynę przełączenia, czas rozpoczęcia i zakończenia operacji, stan replikacji przed wymuszeniem oraz czynności wykonane po odzyskaniu usługi. Warto również zweryfikować kopie zapasowe, procedury odtwarzania i monitoring opóźnienia replikacji. Jeżeli failover forced był skutkiem błędnego pomiaru stanu węzła, problemu z quorum albo niesprawnej komunikacji, samo przełączenie nie usuwa źródła ryzyka. Rzetelna diagnostyka obejmuje więc analizę dzienników systemowych, komunikatów mechanizmu replikacji, stanu dysków i połączeń sieciowych oraz test kontrolowanego powrotu do prawidłowej topologii.