0Pricing
SQL Academy · Lektion

Failover und Leader Election (Patroni, Stolon)

Verwenden Sie Patroni oder Stolon für automatisches Failover und konfigurieren Sie ein Quorum, um Split-Brain-Situationen zu vermeiden.

Failover und Leader Election (Patroni, Stolon) ist eine kostenlose SQL Academy-Lektion auf CoddyKit. Dies ist Lektion 3 von 4. Du kannst die komplette Lektion unten kostenlos lesen – dann übst du sie direkt im Browser mit einem integrierten Code-Editor und einem KI-Tutor rund um die Uhr. Sie ist Teil des SQL Academy-Lernpfads, und dein Fortschritt wird über Web und CoddyKit-App synchronisiert. Der SQL Academy-Kurs umfasst insgesamt 4 Lektionen.

Warum automatisches Failover?

Manuelles Failover ist langsam und fehleranfällig. Tools erkennen den Ausfall des Primärservers und stufen ein Replikat ohne menschliches Eingreifen hoch.

Failover-Schritte

Folgendes muss geschehen:

  1. Erkennen, dass der Primärserver ausgefallen ist (Health Checks, Konsens)
  2. Ein Replikat mit dem aktuellsten WAL auswählen
  3. Es hochstufen (pg_promote / pg_ctl promote)
  4. Die anderen Replikate so konfigurieren, dass sie dem neuen Primärserver folgen
  5. Das Routing der Anwendung aktualisieren

Split-Brain-Risiko

Wenn das Netzwerk in getrennte Bereiche zerfällt, könnten Sie ein Replikat hochstufen, während der alte Primärserver noch aktiv ist. Zwei Primärserver → widersprüchliche Schreibvorgänge → Datenbeschädigung. Vermeiden Sie dies mit Quorum.

Patroni

Python-Daemon, der für die Leader-Wahl einen externen DCS (Distributed Configuration Store) verwendet – typischerweise etcd, Consul oder Zookeeper:

# 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

Wie Patroni den neuen Leader auswählt

Der Patroni-Daemon jedes Knotens versucht, eine Leader-Sperre in etcd zu erwerben. Nur einer kann sie halten; dieser Knoten wird zum Primärserver. Die anderen folgen ihm.

Stolon

Alternative auf Go-Basis. Verwendet ein ähnliches Konsensmodell, weist aber andere operative Eigenschaften auf. Teilt die Verantwortlichkeiten zwischen den Komponenten sentinel, keeper und proxy auf.

repmgr

Leichteres Tool von 2ndQuadrant – weniger Automatisierung, mehr manuelle Kontrolle. Gut für kleinere Umgebungen.

Cloud-verwaltetes Failover

RDS, Cloud SQL und Aurora übernehmen das Failover für Sie. Sie erhalten einfacheren Betrieb auf Kosten von Flexibilität.

Verbindungsrouting nach einem Failover

Anwendungen müssen den neuen Primärserver kennen. Möglichkeiten:

  • DNS-Aktualisierung (wegen TTL langsam)
  • Vom Failover-Tool verwaltete Floating IP
  • Proxy-Schicht: HAProxy, pgbouncer + Skript, AWS-RDS-Endpunkt

Synchrone Replikation und Failover

Synchrones Standby = garantiert kein Datenverlust. Kombinieren Sie dies mit automatischem Failover für maximale Hochverfügbarkeit.

Quorum

Setzen Sie für synchrone Replikation synchronous_standby_names mit Quorum: ANY 2 of 3 Replikate müssen bestätigen. Dadurch wird ein langsames oder ausgefallenes Replikat toleriert, ohne Commits zu blockieren.

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

Eigene Schreibvorgänge lesen

Nach einem Failover oder bei Replikationsverzögerung kann eine Anwendung auf den neuen Primärserver schreiben und anschließend veraltete Daten von einem Replikat lesen. Leiten Sie Lesevorgänge nach Schreibvorgängen entweder an den Primärserver weiter oder verwenden Sie die Nachverfolgung mit pg_last_wal_replay_lsn.

Failover testen

Testen Sie, bevor Sie es benötigen. Beenden Sie den Primärserver monatlich in der Staging-Umgebung. Üben Sie das Runbook. Der Stress eines echten Failovers ist bereits groß genug – Überraschungen machen ihn noch schlimmer.

Zusammenfassung

Automatisches Failover nimmt den Menschen aus einem kritischen Ablauf heraus.

  • Patroni / Stolon für selbstverwaltete Umgebungen
  • RDS / Cloud SQL für verwaltete Umgebungen
  • Vorsicht vor Split-Brain – verwenden Sie Quorum
  • Failover regelmäßig üben

Kurzer Check

Was bedeutet „Split-Brain“ im Kontext der PostgreSQL-Replikation?

Häufig gestellte Fragen

Ist die Lektion „Failover und Leader Election (Patroni, Stolon)“ kostenlos?

Ja — der vollständige Text von „Failover und Leader Election (Patroni, Stolon)“ ist hier im Web kostenlos zu lesen. Um sie interaktiv zu üben (integrierter Code-Editor und 24/7 KI-Tutor) und den Rest des SQL Academy-Kurses freizuschalten, upgrade auf CoddyKit PRO. Der SQL Academy-Kurs umfasst insgesamt 4 Lektionen.

Was lerne ich in „Failover und Leader Election (Patroni, Stolon)“?

Verwenden Sie Patroni oder Stolon für automatisches Failover und konfigurieren Sie ein Quorum, um Split-Brain-Situationen zu vermeiden. Du übst SQL Academy mit praktischem Code, den du direkt im Browser ausführst, und ein 24/7 KI-Tutor beantwortet deine Fragen während du die Lektion bearbeitest.

Brauche ich Erfahrung, um SQL Academy zu starten?

Keine Vorkenntnisse erforderlich. SQL Academy auf CoddyKit ist für Anfänger bis fortgeschrittene Lernende strukturiert, sodass du hier starten oder von Anfang an beginnen und in deinem eigenen Tempo voranschreiten kannst. Dies ist Lektion 3 von 4.

Wie lange dauert die Lektion „Failover und Leader Election (Patroni, Stolon)“?

Die meisten CoddyKit-Lektionen dauern etwa 5–10 Minuten. Jede ist kompakt und interaktiv, sodass du stetig Fortschritte machst und genau dort weitermachst, wo du aufgehört hast – im Web und in der App.

Kann ich in dieser SQL Academy-Lektion Code schreiben und ausführen?

Ja. Jede SQL Academy-Lektion enthält einen integrierten Code-Editor, sodass du echten Code direkt in deinem Browser schreibst und ausführst und sofort KI-Feedback erhältst — ohne lokale Einrichtung erforderlich.

Alle Lektionen in diesem Kurs

  1. Streaming-Replikation und WAL
  2. Logische Replikation für Sharding
  3. Failover und Leader Election (Patroni, Stolon)
  4. Read Replicas und Verbindungsrouting
← Zurück zu SQL Academy