PostgreSQL braucht Hochverfügbarkeit? PostgreSQL HA konfigurieren

Veröffentlicht am:

Fällt der Datenbankserver deines Shops aus, verlieren Kunden bis zur Wiederherstellung den Zugriff. Betrifft der Ausfall die gesamte Verfügbarkeitszone, kann die Unterbrechung länger dauern. Du brauchst einen weiteren Server, der mit den bestätigten Daten übernehmen kann. High availability (HA) hält einen synchron replizierten Standby bereit; zonenredundante HA platziert ihn in einer anderen Zone derselben Region. Azure macht ihn bei einem entsprechenden Ausfall zum primären Server.

Vorhandenen PostgreSQL-Server verwenden

Verwende pg-ctappweu, Datenbank appdb und Tabelle products aus PostgreSQL-Server erstellen in rg-cloudtrips-pg-test-weu. Erstelle sie erneut, falls gelöscht. Verwende dein ctadmin-Passwort und die vorhandene VS-Code-Verbindung.

Öffne pg-ctappweu → Compute + storage. Wechsle von Burstable zu General Purpose und wähle eine kleine verfügbare Größe, beispielsweise 2 vCores. Behalte die Speichergröße bei, prüfe den Preis und speichere. Warte auf den Abschluss; die Compute-Änderung kann Verbindungen kurz unterbrechen. HA erfordert General Purpose oder Memory Optimized.

Standby hinzufügen

Öffne pg-ctappweu → Settings → High availability. Setze Zonal resiliency: Enabled. Bietet dein Portal eine Auswahl des HA-Modus, wähle Zone redundant. Wähle Save, prüfe die zusätzlichen Standbykosten und bestätige Enable high availability.

Bietet Azure wegen fehlender zonenübergreifender Kapazität einen Standby in derselben Zone als Ausweichoption, ermöglicht dieser weiterhin Failover bei Serverausfällen. Prüfe den entstandenen Modus: Schutz gegen den Ausfall einer ganzen Zone erfordert unterschiedliche Zonen für primären Server und Standby.

Warte auf den HA-Status Healthy.

PostgreSQL-Seite High availability mit Status Healthy, HA-Modus sowie primärer und Standby-Verfügbarkeitszone

In dieser Aufnahme bedeuten High availability mode: Same zone, Status: Healthy und Primary availability zone: 3, dass primärer Server und Standby in Zone 3 liegen. Die aktivierte Ausweichoption erlaubt dies bei fehlender zonenübergreifender Kapazität; sobald Kapazität verfügbar ist, erfolgt eine automatische Migration. Zonennummern und Modus können je nach Bereitstellung abweichen. Prüfe bei Zone redundant, dass die beiden Zonen verschieden sind. Der Standby erhält Transaktionsprotokolle synchron, bevor Commits bestätigt werden. Dadurch bleiben bestätigte Transaktionen beim Failover erhalten. Er dient als Failoverziel; leselastige Anwendungen verwenden separate Lesereplikate.

Geplantes Failover testen

Verbinde dich zunächst in VS Code mit appdb und prüfe mit der folgenden Abfrage, dass die Produktzeile vorhanden ist. Wähle anschließend auf High availability die Option Planned failover → Initiate planned failover. Vorhandene Sitzungen werden beim Wechsel getrennt.

Warte auf den Abschluss und aktualisiere die HA-Seite.

High-availability-Seite nach geplantem Failover mit Status Healthy und erfolgreicher Abschlussmeldung

Bei Same zone bleibt die Zonennummer gleich. Prüfe die erfolgreiche Failovermeldung und den Status Healthy, anschließend die Datenbankverbindung wie unten beschrieben. Bei Zone redundant sollten primäre und Standby-Zone ihre Rollen getauscht haben.

Verbinde dich erneut über dieselbe Adresse pg-ctappweu.postgres.database.azure.com, Datenbank appdb, und führe aus:

SELECT current_database() AS database_name,
       pg_is_in_recovery() AS is_standby;
SELECT product_id, name, price FROM products;

Abfrage nach dem Failover mit appdb, is_standby false und dem vorhandenen Produkt Notebook

Erwarte appdb, false und die ursprüngliche Zeile Notebook / 12.50. false bedeutet, dass diese Verbindung den primären Server erreicht hat. Der Endpunkt bleibt gleich, während Azure den Server dahinter wechselt; Anwendungen benötigen Wiederholungslogik für Verbindungen. Der Test prüft Neuverbindung und Datenzugriff nach einem geplanten Wechsel.

Warte vor einem weiteren Failover 15–20 Minuten und auf gesunde HA, damit der neue Standby bereit werden kann.

Behalten oder Labkosten senken

Behalte den Server für die PITR- und Lesereplikat-Trips. Um zwischen Labs Kosten zu senken, deaktiviere HA, warte auf den Abschluss und skaliere dann auf Burstable B1ms zurück. Für Lesereplikate brauchst du anschließend wieder eine geeignete Compute-Ebene. Lösche alternativ rg-cloudtrips-pg-test-weu, sobald alle Übungen abgeschlossen sind.