Po awarii primary aplikacja nie widzi nowego mastera - VIP i HAProxy

PostgreSQL

Po awarii primary aplikacja nie widzi nowego mastera - VIP i HAProxy

W skrócie

Automatyczny failover to dopiero połowa sukcesu. Baza może poprawnie wypromować nowy węzeł, a mimo to aplikacja pozostanie odcięta, bo wciąż puka do maszyny, która padła. Wyjaśnimy, dlaczego tak się dzieje i jak zbudować warstwę dostępową, dzięki której klient zawsze trafi na aktualny serwer główny.

Jak to wygląda w praktyce

Serwer główny pada, a klaster HA (na przykład zarządzany przez Patroni) w kilkanaście sekund promuje jeden z serwerów zapasowych na nowy primary. Z punktu widzenia bazy wszystko zadziałało: nowy węzeł przyjmuje zapisy. Tymczasem aplikacja rzuca błędami połączenia, bo w jej konfiguracji figuruje adres IP starej maszyny. Ktoś musi ręcznie zmienić connection string i zrestartować aplikację, przez co realny przestój trwa nie kilkanaście sekund, lecz tyle, ile zajmie interwencja człowieka. Cel wysokiej dostępności zostaje zaprzepaszczony.

Dlaczego tak się dzieje

Failover odbywa się wewnątrz klastra bazy. Mechanizm HA wie, który węzeł jest teraz główny, ale nie ma żadnej mocy nad tym, dokąd łączy się aplikacja. Klient używa adresu, który mu podano, i jeśli jest to konkretny adres jednego serwera, po jego awarii po prostu nie ma z kim rozmawiać. Brakuje pośrednika, który wiedziałby o zmianie roli i kierował ruch we właściwe miejsce.

Rozwiązuje to warstwa dostępowa. Pierwsze podejście to pływający adres VIP: jeden wirtualny adres IP, który w danej chwili jest przypisany do węzła pełniącego rolę głównego i przy failoverze wędruje na nowy węzeł. Drugie podejście to proxy, najczęściej HAProxy, do którego łączy się aplikacja i które rozdziela połączenia na aktualnego mastera. HAProxy rozpoznaje, który węzeł jest główny, odpytując go zdrowotnym sprawdzeniem - w klastrach Patroni służy do tego wbudowany REST API, którego endpoint zwraca inny kod HTTP dla lidera i dla repliki.

Jak to rozwiązać krok po kroku

1. Ustal jeden stabilny punkt wejścia dla aplikacji i wpisz go do connection stringa raz na zawsze. Może to być adres VIP albo adres HAProxy - aplikacja nigdy nie powinna znać adresów pojedynczych węzłów.
2. Jeśli wybierasz HAProxy, skonfiguruj dwa frontendy: jeden na zapisy kierowany do lidera i opcjonalnie drugi na odczyty rozkładany na repliki. Rozdzielenie ruchu odczytowego i zapisowego pozwala odciążyć głównego.
3. W sekcji backend zapisowego ustaw sprawdzenie zdrowia oparte na endpoincie lidera klastra, na przykład zapytanie HTTP do REST API Patroni na ścieżkę /primary. Węzeł, który nie jest liderem, zwróci kod inny niż 200 i HAProxy go pominie.
4. Dobierz krótkie interwały sprawdzeń zdrowia, żeby proxy szybko zauważyło zmianę lidera. Zbyt długie odstępy wydłużają czas, przez który ruch trafia w próżnię po failoverze.
5. Alternatywnie zbuduj rozwiązanie na VIP i menedżerze, który przy zmianie roli przenosi adres na nowego lidera. To mniej ruchomych części, ale wymaga, żeby wszystkie węzły były w jednej podsieci warstwy drugiej.
6. Przetestuj przełączenie ręcznie, wywołując kontrolowany failover, zanim zaufasz mechanizmowi w produkcji. Obserwuj, po ilu sekundach aplikacja odzyskuje połączenie bez ingerencji człowieka.

Jak sprawdzić, że zadziałało

Wykonaj kontrolowany failover i mierz, ile trwa przerwa widziana przez aplikację - przy dobrze ustawionym HAProxy powinno to być kilka sekund, bez żadnej ręcznej zmiany konfiguracji. Do którego węzła faktycznie trafiasz, sprawdzisz, łącząc się przez punkt wejścia i wykonując SELECT pg_is_in_recovery(); - odpowiedź f potwierdza, że proxy albo VIP wskazuje na serwer główny, a nie na replikę. W statystykach HAProxy (strona stanu albo gniazdo administracyjne) upewnij się, że jako aktywny w backendzie zapisowym widnieje dokładnie jeden węzeł. Powtórz test po ponownym uruchomieniu starego węzła: musi wrócić jako replika, a ruch zapisowy pozostać na nowym liderze - to dowód, że warstwa dostępowa poprawnie śledzi rolę i nie rozjeżdża się z klastrem.

Wróć do listy: 100 najczęstszych pytań i problemów z PostgreSQL

Sprawdź szkolenie: Administracja, replikacja i tuning baz danych PostgreSQL

To szkolenie może być dofinansowane z KFS lub BUR.

★★★★★Średnia ocena naszych szkoleń w Google: 5/5

Sprawdź szkolenie: Zaawansowana administracja PostgreSQL (HA, DR, monitoring, skalowanie)

To szkolenie może być dofinansowane z KFS lub BUR.

★★★★★Średnia ocena naszych szkoleń w Google: 5/5