AlloyDB-Hochverfügbarkeit – Übersicht

In diesem Dokument finden Sie eine Übersicht über die Hochverfügbarkeitskonfiguration (HA) für AlloyDB for PostgreSQL-Instanzen. Informationen zum Konfigurieren einer neuen Instanz mit hoher Verfügbarkeit oder zum Aktivieren der hohen Verfügbarkeit für eine vorhandene Instanz finden Sie unter Cluster- und Instanzeinstellungen ansehen.

Eine HA-Konfiguration sorgt dafür, dass der Betrieb auch nach Ausfallereignissen fortgesetzt werden kann. Bei zonalen Instanzen kann es bei Ausfallereignissen zu längeren Ausfallzeiten kommen. Mit HA bleiben Ihre Daten jedoch für Clientanwendungen verfügbar.

Primäre und sekundäre Instanzen

Eine primäre AlloyDB-Instanz, die für Hochverfügbarkeit konfiguriert ist, enthält einen aktiven Knoten und einen Standby-Knoten, die sich in verschiedenen Zonen befinden. Für den Speicher verwendet AlloyDB einen regionalen Log-Persistor zum Speichern von Datenbank-Write-Ahead-Logs (WAL) und den regionalen Speicherdienst von AlloyDB zum Speichern von Datenblöcken. Die IP-Adresse der Instanz leitet den Traffic über einen Load Balancer an den aktiven Knoten weiter.

Beim Verarbeiten von Schreibvorgängen schreibt die AlloyDB-Datenbank zuerst WAL in den regionalen Log-Persistor auf dem aktiven Knoten und überträgt die Logs dann asynchron an die regionalen Log-Verarbeitungsserver von AlloyDB, die die Logs in Datenblöcke für die langfristige Speicherung umwandeln. Anschließend bereinigt AlloyDB die Logs, die erfolgreich verarbeitet wurden.

Das folgende Diagramm zeigt die Hochverfügbarkeitsarchitektur.

Hochverfügbarkeitsarchitektur

Abbildung 1 : Hochverfügbarkeitsarchitektur

Failover

Wenn der aktive Knoten nicht mehr verfügbar ist, führt AlloyDB automatisch ein Failover der primären Instanz auf den Standby-Knoten durch, der zum neuen aktiven Knoten wird. Der Load Balancer erkennt den neuen aktiven Knoten und leitet den Traffic dorthin weiter. Nach einem Failover bleibt der neue aktive Knoten aktiv, auch wenn der ursprüngliche Knoten wieder online ist. Bei einem Failover kommt es aufgrund synchroner WAL-Schreibvorgänge in den regionalen Log-Persistor nicht zu Datenverlusten.

Das folgende Diagramm zeigt den Trafficfluss nach einem Failover.

Trafficfluss nach Failover

Abbildung 2 : Trafficfluss nach einem Failover

Ein Failover tritt in der folgenden Ereignisabfolge auf:

  1. Der aktive Knoten oder die aktive Zone fällt aus. Das AlloyDB-System zur Systemdiagnose prüft regelmäßig, ob der aktive Knoten fehlerfrei ist. Wenn das System zur Systemdiagnose mehrere Prüfungen nicht besteht, wird ein Failover ausgelöst. Diese Erkennung kann bis zu 30 Sekunden dauern.
  2. Die Datenbank wird auf dem Standby-Knoten gestartet und akzeptiert Verbindungen. Das dauert in der Regel weniger als 30 Sekunden.
  3. Der Standby-Knoten wird zum primären Knoten hochgestuft. Über die statische IP-Adresse der Instanz beginnt der neue primäre Knoten mit der Bereitstellung von Daten und Clientabfragen sind nach einer erneuten Verbindung erfolgreich.
  4. AlloyDB erstellt einen Standby-Knoten in der zuvor aktiven Zone neu. Dieser Standby-Knoten ist dann für zukünftige Failover bereit.

Voraussetzungen

Damit AlloyDB ein Failover zulässt, muss die Konfiguration die folgenden Anforderungen erfüllen:

  • Die primäre Instanz muss in einem normalen Betriebszustand sein, d. h. sie darf nicht angehalten sein oder gewartet werden.
  • Die Standby-Zone und der Standby-Knoten müssen beide fehlerfrei sein.

Neue Architektur

Neu erstellte AlloyDB-Instanzen mit PostgreSQL 18 bieten ein verbessertes Failover mit einem Lesereplikat auf dem Standby-Knoten (Hot-Standby-Knoten).

AlloyDB enthält ein Lesereplikat auf dem Hot-Standby-Knoten. Bei einem Failover kann dieses Lesereplikat schneller in den Lese-/Schreibmodus wechseln, wodurch die Ausfallzeit reduziert wird. Außerdem ermöglicht das Lesereplikat warme Caches, was für eine konsistente Abfrageleistung nach dem Failover sorgt.

Das folgende Diagramm zeigt die Hochverfügbarkeitsarchitektur mit dem Hot Standby-Knoten. Hot-Standby

Abbildung 3 : Hot-Standby-Knoten

Lesepools

Lesepoolinstanzen mit mindestens zwei Knoten sind hochverfügbar. Knoten werden gleichmäßig auf die Zonen verteilt, wodurch die Ausfallsicherheit bei Ausfallereignissen erhöht wird. Bei Ausfallereignissen wie einem Knoten- oder Zonenausfall leitet ein regionaler Load Balancer den Traffic an die verbleibenden fehlerfreien Knoten weiter, sodass für Ihre Kunden keine Ausfallzeiten entstehen.

Lesepools bleiben während eines Failovers der primären Instanz online. Die WAL-Replikation von der primären Instanz wird während des Failovers vorübergehend angehalten und automatisch fortgesetzt, nachdem die primäre Instanz wiederhergestellt wurde.

Nächste Schritte