PricingLoginStart free
SQL Academy · Lektion

Failover og ledervalg (Patroni, Stolon)

Brug Patroni eller Stolon til automatisk failover, og konfigurér quorum for at undgå split-brain.

Lektion 3 af 415 trin

Failover og ledervalg (Patroni, Stolon) er en gratis SQL Academy-lektion på CoddyKit. Dette er lektion 3 af 4. Du kan læse hele lektionen gratis nedenfor — og derefter øve dig praktisk i browseren med en indbygget kodeeditor og en AI-vejleder, der er tilgængelig døgnet rundt. Den er en del af læringsforløbet i SQL Academy, og dine fremskridt synkroniseres på tværs af nettet og CoddyKit-appen. SQL Academy-kurset indeholder 4 lektioner i alt.

Hvorfor automatisk failover?

Manuelt failover er langsomt og fejlbehæftet. Værktøjer registrerer svigt på primærserveren og promoverer en replika uden menneskelig indgriben.

Trin ved failover

Følgende skal ske:

  1. Registrér, at primærserveren er nede (tilstandstjek og konsensus)
  2. Vælg den replika, der har den seneste WAL
  3. Promovér den (pg_promote / pg_ctl promote)
  4. Omkonfigurer de andre replikaer, så de følger den nye primærserver
  5. Opdatér applikationens forbindelsesdirigering

Risiko for split brain

Hvis netværket bliver opdelt, kan du promovere en replika, mens den gamle primærserver stadig er i drift. To primærservere → modstridende skrivninger → datakorruption. Undgå det med kvorum.

Patroni

En Python-dæmon, der bruger et eksternt DCS (distribueret konfigurationslager) — typisk etcd, Consul eller Zookeeper — til ledervalg:

# 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

Sådan vælger Patroni den nye leder

Patroni-dæmonen på hver node konkurrerer om at få en lederlås i etcd. Kun én kan have den, og den node bliver primærserveren. De andre følger den.

Stolon

Et Go-baseret alternativ. Det bruger en lignende konsensusmodel, men med andre driftsegenskaber. Det fordeler ansvaret mellem komponenterne sentinel, keeper og proxy.

repmgr

Et lettere værktøj fra 2ndQuadrant — mindre automatisering og mere manuel kontrol. Velegnet til mindre opsætninger.

Cloud-administreret failover

RDS, Cloud SQL og Aurora håndterer failover for dig. Du bytter fleksibilitet for enklere drift.

Forbindelsesdirigering efter failover

Applikationer skal kende den nye primærserver. Muligheder:

  • DNS-opdatering (langsom på grund af TTL)
  • Flydende IP-adresse, som administreres af failover-værktøjet
  • Proxy-lag: HAProxy, pgbouncer + script eller AWS RDS-slutpunkt

Synkron replikering og failover

Synkron standby = garanteret intet datatab. Kombinér det med automatisk failover for den stærkeste HA.

Kvorum

Ved synkron replikering skal du indstille synchronous_standby_names med kvorum: 2 af 3 replikaer skal bekræfte. Det tåler én langsom eller fejlramt replika uden at blokere commits.

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

Læs dine egne skrivninger

Efter failover eller ved replikeringsforsinkelse kan en applikation skrive til den nye primærserver og straks læse forældede data fra en replika. Dirigér enten læsninger efter skrivninger til primærserveren, eller brug sporing med pg_last_wal_replay_lsn.

Test af failover

Test det, før du får brug for det. Stop primærserveren i testmiljøet hver måned. Øv driftsvejledningen. Belastningen ved et ægte failover er slem nok; overraskelser gør det værre.

Opsummering

Automatisk failover fjerner mennesker fra en kritisk arbejdsgang.

  • Patroni / Stolon til selvadministrerede opsætninger
  • RDS / Cloud SQL til administrerede opsætninger
  • Pas på split brain — brug kvorum
  • Øv failover regelmæssigt

Hurtig test

Hvad er "split brain" i forbindelse med PostgreSQL-replikering?

Besvar den i den interaktive lektion
Gratis at komme i gang

Lær SQL med en AI-underviser — gratis

Skriv og kør rigtig kode i din browser, få øjeblikkelig hjælp fra en AI-underviser døgnet rundt, og fortsæt, hvor du slap, på web eller i appen.

Kurser
46
Lektioner
183
Start gratisSe hele kurset

Ofte stillede spørgsmål

Er lektionen “Failover og ledervalg (Patroni, Stolon)” gratis?

Ja — hele teksten til “Failover og ledervalg (Patroni, Stolon)” kan læses gratis her på nettet. Hvis du vil øve dig interaktivt med en indbygget kodeeditor og en AI-vejleder døgnet rundt og få adgang til resten af SQL Academy-kurset, skal du opgradere til CoddyKit PRO. SQL Academy-kurset indeholder 4 lektioner i alt.

Hvad lærer jeg i “Failover og ledervalg (Patroni, Stolon)”?

Brug Patroni eller Stolon til automatisk failover, og konfigurér quorum for at undgå split-brain. Du øver dig i SQL Academy med praktisk kode, som du kører direkte i browseren, og en AI-vejleder døgnet rundt besvarer dine spørgsmål, mens du arbejder dig gennem lektionen.

Skal jeg have erfaring for at begynde på SQL Academy?

Der kræves ingen tidligere erfaring. SQL Academy på CoddyKit er tilrettelagt for både begyndere og øvede, så du kan starte her eller fra begyndelsen og lære i dit eget tempo. Dette er lektion 3 af 4.

Hvor lang tid tager lektionen “Failover og ledervalg (Patroni, Stolon)”?

De fleste CoddyKit-lektioner tager cirka 5–10 minutter. Hver lektion er kort og interaktiv, så du gør løbende fremskridt og kan fortsætte, hvor du slap – på både web og app.

Kan jeg skrive og køre kode i denne SQL Academy-lektion?

Ja. Alle SQL Academy-lektioner har en indbygget kodeeditor, så du kan skrive og køre rigtig kode direkte i din browser og få øjeblikkelig feedback fra AI – uden lokal opsætning.

Alle lektioner i dette kursus

  1. Streaming-replikering og WAL
  2. Logisk replikering til sharding
  3. Failover og ledervalg (Patroni, Stolon)
  4. Læse-replikaer og forbindelsesrouting
← Tilbage til SQL Academy