0Pricing
SQL Academy · Lekcja

Failover i wybór lidera (Patroni, Stolon)

Używać Patroni lub Stolon do automatycznego przełączania awaryjnego i konfigurować kworum, aby uniknąć split-brain

Failover i wybór lidera (Patroni, Stolon) to bezpłatna lekcja SQL Academy na CoddyKit. To lekcja 3 z 4. Możesz przeczytać całą lekcję poniżej za darmo — a potem ćwiczyć ją interaktywnie w przeglądarce z wbudowanym edytorem kodu i tutorem AI dostępnym 24/7. To część ścieżki edukacyjnej SQL Academy, a Twój postęp synchronizuje się między webem a aplikacją CoddyKit. Kurs SQL Academy zawiera 4 lekcji w sumie.

Dlaczego automatyczny failover?

Ręczny failover jest powolny i podatny na błędy. Narzędzia wykrywają awarię serwera głównego i promują replikę bez udziału człowieka.

Kroki failover

Muszą zajść następujące zdarzenia:

  1. Wykrycie niedostępności serwera głównego (kontrole stanu, konsensus)
  2. Wybór repliki z najnowszym WAL
  3. Promowanie jej (pg_promote / pg_ctl promote)
  4. Przekonfigurowanie pozostałych replik, aby podążały za nowym serwerem głównym
  5. Aktualizacja routingu połączeń aplikacji

Ryzyko split brain

Jeśli sieć zostanie podzielona, można promować replikę, podczas gdy stary serwer główny nadal działa. Dwóch serwerów głównych oznacza sprzeczne zapisy i uszkodzenie danych. Należy temu zapobiegać za pomocą kworum.

Patroni

Daemon napisany w Pythonie, który korzysta z zewnętrznego magazynu konfiguracji rozproszonej (DCS) — zazwyczaj etcd, Consul lub Zookeeper — do wyboru lidera:

# patroni.yml
name: pg1
scope: my_cluster
etcd:
  hosts: 10.0.0.10:2379,10.0.0.11:2379,10.0.0.12:2379
postgresql:
  data_dir: /var/lib/postgresql/data

Jak Patroni wybiera nowego lidera

Daemon Patroni na każdym węźle rywalizuje o uzyskanie blokady lidera w etcd. Tylko jeden węzeł może ją posiadać; ten węzeł staje się serwerem głównym. Pozostałe podążają za nim.

Stolon

Alternatywne narzędzie napisane w Go. Korzysta z podobnego modelu konsensusu, ale ma inne cechy operacyjne. Dzieli odpowiedzialność między komponenty sentinel, keeper i proxy.

repmgr

Lżejsze narzędzie od 2ndQuadrant — zapewnia mniej automatyzacji, ale większą kontrolę ręczną. Dobrze sprawdza się w mniejszych środowiskach.

Failover zarządzany przez dostawcę chmurowego

RDS, Cloud SQL i Aurora obsługują failover za użytkownika. W zamian za prostszą obsługę operacyjną trzeba zaakceptować mniejszą elastyczność.

Routing połączeń po failover

Aplikacje muszą znać nowy serwer główny. Dostępne opcje:

  • Aktualizacja DNS (powolna z powodu TTL)
  • Floating IP zarządzany przez narzędzie failover
  • Warstwa proxy: HAProxy, pgbouncer + skrypt, endpoint AWS RDS

Replikacja synchroniczna a failover

Synchroniczna replika zapasowa gwarantuje brak utraty danych. Połączenie jej z automatycznym failover zapewnia najwyższy poziom HA.

Kworum

W przypadku replikacji synchronicznej ustaw synchronous_standby_names z kworum: ANY 2 of 3 replik muszą potwierdzić operację. Pozwala to tolerować jedną wolną lub uszkodzoną replikę bez blokowania zatwierdzania transakcji.

synchronous_standby_names = 'ANY 2 (replica1, replica2, replica3)'

Read-Your-Writes

Po failover lub przy opóźnieniu replikacji aplikacja może zapisać dane na nowym serwerze głównym, a następnie natychmiast odczytać nieaktualne dane z repliki. Należy kierować odczyty po zapisie do serwera głównego albo używać śledzenia za pomocą pg_last_wal_replay_lsn.

Testowanie failover

Przetestuj failover, zanim będzie potrzebny. Co miesiąc wyłączaj serwer główny w środowisku stagingowym. Ćwicz procedurę operacyjną. Rzeczywisty failover jest wystarczająco stresujący — niespodzianki tylko pogarszają sytuację.

Podsumowanie

Automatyczny failover usuwa udział człowieka z krytycznej ścieżki.

  • Patroni / Stolon w środowiskach zarządzanych samodzielnie
  • RDS / Cloud SQL w usługach zarządzanych
  • Uważaj na split brain — używaj kworum
  • Regularnie ćwicz procedurę failover

Szybkie sprawdzenie

Czym jest „split brain” w kontekście replikacji PostgreSQL?

Często zadawane pytania

Czy lekcja „Failover i wybór lidera (Patroni, Stolon)” jest bezpłatna?

Tak — pełny tekst „Failover i wybór lidera (Patroni, Stolon)” jest dostępny za darmo tutaj w sieci. Aby ćwiczyć ją interaktywnie (wbudowany edytor kodu i tutor AI dostępny 24/7) i odblokować resztę kursu SQL Academy, przejdź na CoddyKit PRO. Kurs SQL Academy zawiera 4 lekcji w sumie.

Co nauczysz się w „Failover i wybór lidera (Patroni, Stolon)”?

Używać Patroni lub Stolon do automatycznego przełączania awaryjnego i konfigurować kworum, aby uniknąć split-brain Ćwiczysz SQL Academy z praktycznym kodem, który uruchamiasz bezpośrednio w przeglądarce, a tutor AI dostępny 24/7 odpowiada na Twoje pytania podczas pracy nad lekcją.

Czy potrzebuję doświadczenia, aby zacząć SQL Academy?

Nie wymagamy żadnego doświadczenia. SQL Academy w CoddyKit jest strukturyzowany dla początkujących i zaawansowanych użytkowników, więc możesz zacząć tutaj lub od początku i uczyć się w swoim tempie. To lekcja 3 z 4.

Ile czasu zajmuje lekcja „Failover i wybór lidera (Patroni, Stolon)”?

Większość lekcji CoddyKit trwa około 5–10 minut. Każda lekcja to mały, interaktywny krok, dzięki czemu robisz systematyczne postępy i zawsze wracasz dokładnie do tego samego miejsca — na webie i w aplikacji.

Czy mogę pisać i uruchamiać kod w tej lekcji SQL Academy?

Tak. Każda lekcja SQL Academy zawiera wbudowany edytor kodu, więc piszesz i uruchamiasz prawdziwy kod bezpośrednio w przeglądarce i od razu otrzymujesz sprzężenie zwrotne od AI — bez konfiguracji na komputerze.

Wszystkie lekcje w tym kursie

  1. Replikacja strumieniowa i WAL
  2. Replikacja logiczna na potrzeby shardingu
  3. Failover i wybór lidera (Patroni, Stolon)
  4. Repliki tylko do odczytu i kierowanie połączeniami
← Powrót do SQL Academy