Ustawienia failover

Ustawienia failover określają warunki i tryb automatycznego przełączenia roli podstawowej w grupie dostępności.

Rola ustawień failover w grupie dostępności

Ustawienia failover określają, kiedy i w jaki sposób system może przenieść rolę podstawowej repliki na inną replikę należącą do grupy dostępności. Podstawowa replika przyjmuje operacje zapisu, natomiast repliki pomocnicze otrzymują kopie zmian zgodnie z konfiguracją synchronizacji. Przełączenie awaryjne ma ograniczyć przerwę w dostępie do danych w sytuacji, gdy podstawowa replika przestaje działać, traci połączenie z pozostałą częścią infrastruktury albo nie spełnia warunków uznanych za krytyczne.

W praktyce failover nie oznacza zwykłego ponownego uruchomienia usługi. Podczas przełączenia nowa replika podstawowa musi posiadać odpowiedni stan danych, a klienci muszą otrzymać możliwość połączenia z nowym właścicielem roli. Znaczenie mają więc zarówno parametry samej grupy dostępności, jak i stan replik, dostępność mechanizmu rozpoznawania właściciela zasobu oraz sposób kierowania połączeń przez aplikację. Nieprawidłowe ustawienie któregokolwiek z tych elementów może spowodować przełączenie zakończone błędem albo pozorną dostępność usługi bez aktualnych danych.

Warunki automatycznego przełączenia roli

Jednym z podstawowych parametrów jest tryb failover przypisany do repliki. W środowisku obsługującym automatyczny failover muszą być spełnione warunki określone przez platformę, między innymi odpowiedni tryb dostępności repliki oraz synchroniczne przekazywanie zmian. Replika przeznaczona do automatycznego przejęcia roli powinna być zsynchronizowana z repliką podstawową. Dzięki temu po przełączeniu nie powstaje luka obejmująca transakcje, które zostały zatwierdzone na podstawie, ale nie dotarły jeszcze do repliki pomocniczej.

Konfiguracja może również określać, jakie awarie mają zostać uznane za wystarczający powód do failover. Mechanizm może reagować na niedostępność instancji, utratę połączenia z zasobami grupy, zatrzymanie procesu obsługującego bazę albo inne stany zdefiniowane przez system klastrowy. Zbyt wąskie kryteria mogą pozostawić aplikację przy niedziałającej replice, natomiast zbyt szerokie kryteria zwiększają ryzyko niepotrzebnych przełączeń. Dlatego warunki powinny odpowiadać rzeczywistym zależnościom aplikacji i być sprawdzane podczas testów awaryjnych.

Synchronizacja, quorum i ryzyko utraty danych

Failover jest bezpośrednio związany z trybem synchronizacji replik. W synchronizacji synchronicznej podstawowa replika oczekuje na potwierdzenie przekazania zmiany do repliki partnerskiej przed zakończeniem określonych operacji zapisu. Taki model ogranicza ryzyko utraty ostatnich zatwierdzonych transakcji po przełączeniu, ale może zwiększać opóźnienia zapisu, gdy replika pomocnicza lub połączenie między replikami działa wolniej. W synchronizacji asynchronicznej zmiany są przekazywane bez oczekiwania na pełne potwierdzenie, co lepiej toleruje większą odległość i opóźnienia, lecz w chwili awarii może wystąpić utrata części ostatnich zmian.

Na decyzję o możliwości przełączenia wpływa także quorum, czyli zasada ustalania, czy wystarczająca liczba głosujących elementów klastra pozostaje dostępna. Quorum nie ocenia kompletności danych w taki sam sposób jak stan synchronizacji repliki. Możliwa jest więc sytuacja, w której klaster zachowuje quorum, ale wybrana replika nie jest gotowa do przejęcia roli z powodu opóźnienia synchronizacji, błędów transportu lub zawieszonego ruchu dziennika transakcji. Przed zatwierdzeniem ustawień należy rozdzielić te dwa pojęcia: dostępność klastra nie jest równoznaczna z gotowością każdej repliki do bezpiecznego failover.

Weryfikacja konfiguracji i diagnostyka po przełączeniu

Kontrola ustawień failover powinna obejmować nazwę repliki podstawowej, tryb synchronizacji, stan synchronizacji, tryb failover oraz aktualne opóźnienie przekazywania danych. Należy również sprawdzić, czy mechanizm klastrowy widzi wszystkie wymagane zasoby i czy aplikacja korzysta z punktu połączenia przeznaczonego dla grupy dostępności, a nie ze stałej nazwy pojedynczej instancji. Logi powinny być analizowane w kolejności zdarzeń: utrata dostępności podstawy, ocena warunków, wybór repliki docelowej, przejęcie roli oraz ponowne połączenie klientów.

Test failover powinien być zaplanowany i przeprowadzony w kontrolowanych warunkach, ponieważ samo istnienie ustawienia automatycznego przełączenia nie potwierdza jego poprawności. Po teście trzeba zweryfikować możliwość odczytu i zapisu, stan każdej repliki, opóźnienie synchronizacji oraz zachowanie aplikacji korzystających z bazy. Warto także sprawdzić powrót poprzedniej repliki do grupy, aby wykluczyć sytuację, w której awaria zostaje usunięta technicznie, lecz replika pozostaje poza synchronizacją. Diagnostyka powinna rozróżniać błąd konfiguracji failover od problemu z siecią, usługą bazy danych, dyskiem lub samą aplikacją.