Entscheidung: welche HA/DR-Lösung?

Die Wahl einer Lösung für Hochverfügbarkeit und Disaster Recovery beginnt nicht bei der Technik, sondern beim Gleichgewicht zwischen Geschäftsanforderungen (RTO/RPO), Bedarf an geografischer Verteilung und Kosten. Ausgehend von deiner Toleranz für Ausfallzeit und Datenverlust führt dich dieser Baum zum passenden Ansatz zwischen synchronen Replicas, asynchronen Standbys, Clustern mit automatischem Failover und Backup+PITR.

Wie hoch ist deine Toleranz für Datenverlust (RPO)?

Beginne mit der härtesten Bedingung: Wie viele Sekunden an Daten kannst du dir im Katastrophenfall leisten zu verlieren? Ist null Datenverlust (RPO=0) gefordert, ist synchrone Replikation Pflicht; sind einige Sekunden/Minuten akzeptabel, kommen asynchrone Lösungen und günstigere Ansätze infrage. Das RPO-Ziel bestimmt meist alle weiteren Entscheidungen.

• Null Datenverlust ist Pflicht (RPO = 0)
• Einige Sekunden/Minuten Datenverlust sind akzeptabel

Ist auch eine automatische, schnelle Übernahme (niedrige RTO) gefordert?

Du willst null Datenverlust; aber wie schnell musst du wieder laufen, wenn der Primary ausfällt? Automatisches Failover innerhalb von Sekunden, oder ist ein kurzes Fenster für manuelles Eingreifen akzeptabel? Das entscheidet zwischen einer einfachen synchronen Replica und einem voll automatisierten Cluster.

• Automatisches Failover innerhalb von Sekunden ist gefordert
• Manuelle/geplante Übernahme reicht; null Verlust hat Vorrang

Ist eine andere Region/Geografie erforderlich (DR)?

Ist etwas Datenverlust akzeptabel, ist die eigentliche Frage der Umfang der Ausfallsicherheit: Musst du gegen den Verlust eines ganzen Rechenzentrums/einer Region geschützt sein, oder reicht Schutz gegen den Ausfall eines einzelnen Knotens in derselben Region? Ist geografische Verteilung gefordert, rückt ein asynchroner Standby in den Vordergrund; wenn nicht, werden kostenorientierte Optionen bewertet.

• Ja, eine separate Region gegen geografische Katastrophen ist Pflicht
• Nein, Budget und Einfachheit haben Vorrang

Kannst du eine lange Wiederherstellungszeit (hohe RTO) akzeptieren?

Du bleibst in einer Region und tolerierst etwas Datenverlust. Strebst du die niedrigsten Kosten an, oder willst du einen Standby-Knoten, der bei einem Ausfall schnell übernimmt? Ist eine Wiederherstellung über Stunden akzeptabel, ist Backup+PITR allein der wirtschaftlichste Weg; andernfalls brauchst du einen Warm Standby.

• Ja, eine Wiederherstellung über Stunden ist akzeptabel (am günstigsten)
• Nein, ein Warm Standby, der innerhalb von Minuten übernimmt, ist gefordert

Empfehlung: synchrone Replica (null Datenverlust)

Der Primary schließt einen Commit erst ab, wenn mindestens ein Standby ihn bestätigt; selbst bei Verlust des Primary geht also keine bestätigte Transaktion verloren (RPO=0). Die ideale Lösung innerhalb einer Region mit latenzarmem Netzwerk.

Empfehlung: asynchroner Standby (geografische DR)

Der Standby wendet Änderungen als Stream an, ohne die Commits des Primary zu verzögern. Das ist der Standardweg, eine Kopie in einer anderen Region zu halten, ohne die Schreibperformance zu beeinträchtigen; im Gegenzug wird ein kleines Datenverlustfenster (in Höhe der Replikationsverzögerung) akzeptiert.

Empfehlung: Cluster mit automatischem Failover

Eine Cluster-Lösung, die Health Monitoring, Leader-Wahl und automatische Übernahme kombiniert; sie zielt sowohl auf niedrige RTO (automatisches Failover innerhalb von Sekunden) als auch auf niedrige/null RPO mit einer synchronen Kopie. Der Betriebsaufwand ist höher, menschliches Eingreifen wird aber minimiert.

Empfehlung: Backup + PITR (am wirtschaftlichsten)

Statt eines laufenden Standby werden nur regelmäßige Backups und Point-in-Time-Recovery (PITR) über WAL/Archivlogs vorgehalten. Das ist die kostengünstigste Lösung; der Preis ist, dass die Wiederherstellung Stunden dauern kann (hohe RTO).