Jak ręcznie przełączyć rolę primary (switchover) w Patroni

PostgreSQL

Jak ręcznie przełączyć rolę primary (switchover) w Patroni

W skrócie

W klastrze Patroni to nie administrator ręcznie zatrzymuje i uruchamia PostgreSQL - robi to za nas Patroni, pilnując wpisu lidera w magazynie stanu. Kiedy chcemy planowo przenieść rolę primary, na przykład żeby wykonać prace serwisowe na obecnym liderze, służy do tego switchover. To operacja bez utraty danych i z minimalną przerwą, o ile wykonamy ją właściwym narzędziem, a nie przez systemctl.

Jak to wygląda w praktyce

Najczęstszy błąd to próba potraktowania węzła Patroni jak zwykłego PostgreSQL. Administrator wykonuje systemctl stop postgresql na liderze, spodziewając się spokojnej konserwacji. Patroni wykrywa, że primary zniknął, i natychmiast promuje replikę, a po ponownym uruchomieniu starego węzła dostajemy dwa serwery, które przyjmowały zapisy. W logu widać wtedy rozjazd historii WAL i komunikat diverged timelines. Objawem, że robimy to źle, jest też sytuacja, w której po każdym restarcie serwisu rola primary ląduje na przypadkowym węźle, zamiast tam, gdzie chcemy.

Dlaczego tak się dzieje

Patroni utrzymuje w DCS klucz lidera i nieustannie decyduje, który węzeł ma być primary. Kiedy zatrzymamy proces PostgreSQL poza Patroni, dla klastra wygląda to jak awaria - blokada lidera wygasa, więc startuje automatyczna elekcja i promowana jest replika. Różnica między switchover a failover jest zasadnicza. Switchover to zaplanowana zamiana ról, w której Patroni najpierw upewnia się, że wybrana replika jest w pełni zsynchronizowana, dopiero potem degraduje starego lidera i promuje nowego. Failover to reakcja awaryjna, gdy obecny primary jest niedostępny - może wtedy dojść do utraty ostatnich, jeszcze nieprzesłanych transakcji, jeśli replikacja była asynchroniczna.

Jak to rozwiązać krok po kroku

1. Sprawdź stan klastra: patronictl -c /etc/patroni/config.yml list. Zapamiętaj, który węzeł jest Leader, i upewnij się, że docelowa replika ma stan streaming oraz Lag in MB równy zero.
2. Uruchom planowaną zamianę ról: patronictl switchover. Narzędzie zapyta o nazwę klastra, o węzeł, który ma zostać nowym liderem, oraz o czas wykonania - dla natychmiastowego przełączenia podaj now.
3. Potwierdź operację. Patroni zatrzyma stary primary w kontrolowany sposób, poczeka na dogonienie WAL przez wybraną replikę i wypromuje ją na nowego lidera.
4. Jeśli robisz to nieinteraktywnie w skrypcie, podaj wszystko od razu: patronictl switchover --leader stary-wezel --candidate nowy-wezel --force.
5. Do prac serwisowych na starym liderze użyj po switchoverze patronictl pause, które wstrzymuje automatykę Patroni na czas konserwacji, a po zakończeniu patronictl resume.
6. Do rzeczywistej awarii, gdy primary jest już martwy, użyj patronictl failover - ale tylko wtedy, bo failover nie gwarantuje spójności ostatnich transakcji przy replikacji asynchronicznej.

Jak sprawdzić, że zadziałało

Po switchoverze patronictl list powinno pokazać nowy węzeł w roli Leader, a stary jako Replica ze stanem streaming i zerowym opóźnieniem. Sprawdź też, że aplikacja znowu zapisuje dane oraz że na nowym liderze SELECT pg_is_in_recovery(); zwraca false, a na replikach true. Jeśli w logu Patroni nie ma ostrzeżeń o rozjeździe linii czasu WAL, a stara replika podpięła się bez potrzeby odbudowy z pg_rewind, operacja przebiegła poprawnie i klaster jest w pełni spójny.

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