Gebaut, um nie auszufallen.
Jede Komponente läuft heiß. Aktive und Standby-DB-Knoten replizieren kontinuierlich. Eine virtuelle IP schwebt über dem Cluster — keepalived überwacht den Primary, und sobald er nicht mehr antwortet, läuft der Verkehr über den Standby, bevor der durchschnittliche Zuschauer einen Puffer bemerkt. Das ist kein Postgres-Tutorial, das auf ein SaaS aufgesetzt ist — es ist erstklassige Infrastruktur, über die Ihr Betreiber niemals nachdenken muss.
Drei Knoten, eine Wahrheit.
Ein aktives/Standby-DB-Paar repliziert über ein privates Netzwerk. Ein Paar nginx-Load-Balancer nimmt an VRRP für eine virtuelle IP teil, die zwischen ihnen schwebt. Der Anwendungscluster liest über einen Connection-Pool, der bei einem Wechsel des Primary geleert wird und neu versucht. Jede Verbindung ist doppelt gepfadet.
Was passiert, Sekunde für Sekunde.
Wenn ein Primärknoten ausfällt, geschieht die Wiederherstellung in 4 geordneten Schritten. Bedieneraktion: null. Kundenseitige Störung: kürzer als eine TCP-Neuübertragung.
Heartbeat verloren
Das keepalived des Standby empfängt keine VRRP-Ankündigungen des Primary mehr. Nach 3 verpassten Beacons (~1,5s) befördert sich der Standby selbst.
Promotion + STONITH
Der neue Primary fenct den alten Knoten ab — Power-Off via Cloud-API — und akzeptiert Schreibzugriffe. Die Replikationsrichtung kehrt sich um; der wiederhergestellte Knoten tritt als Standby bei.
Virtuelle IP migriert
Die VRRP-virtuelle IP wechselt zur NIC des neuen Primary. Der Connection-Pool der Anwendungsschicht wird geleert; ausstehende Abfragen werden gegen den neuen Endpunkt erneut versucht.
Stabiler Zustand
Der Dienst ist wiederhergestellt. Der wiederhergestellte Knoten synchronisiert sich, sobald er erreichbar ist, und tritt als warmer Standby bei. Audit-Log-Einträge werden geschrieben. Der Betreiber erhält eine einzige Benachrichtigung — im Nachhinein.