Die Hochverfügbarkeit (High Availability, HA) in AlloyDB for PostgreSQL sorgt dafür, dass Ihre Datenbank bei zonalen oder Instanzausfällen betriebsbereit bleibt und Ihre Daten für Clientanwendungen zugänglich sind. Im Gegensatz zu zonalen Instanzen, bei denen es während eines Ausfalls zu längeren Ausfallzeiten kommen kann, wird bei HA-Instanzen automatisch ein Failover zwischen aktiven und Standby-Knoten in verschiedenen Zonen ausgeführt. Informationen zum Konfigurieren einer Instanz für Hochverfügbarkeit finden Sie unter Cluster- und Instanzeinstellungen aufrufen.
Primäre und sekundäre Instanzen
Eine mit Hochverfügbarkeit konfigurierte primäre AlloyDB-Instanz umfasst einen aktiven Knoten und einen Standby-Knoten, die sich in verschiedenen Zonen befinden. Für den Speicher verwendet AlloyDB einen regionalen Log-Persistor, um Write-Ahead-Logs (WAL) der Datenbank zu speichern, und den regionalen AlloyDB-Speicherdienst, um Datenblöcke zu speichern. Die IP-Adresse der Instanz leitet Traffic über einen Load Balancer an den aktiven Knoten weiter.
Bei der Verarbeitung 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 Logverarbeitungsserver in AlloyDB, die die Logs in Datenblöcke für die langfristige Speicherung materialisieren. AlloyDB bereinigt dann die Logs, die erfolgreich verarbeitet wurden.
Das folgende Diagramm zeigt die 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 Stand-by-Knoten durch, der dann zum neuen aktiven Knoten wird. Der Load Balancer erkennt den neuen aktiven Knoten und beginnt, Traffic dorthin weiterzuleiten. Nach einem Failover bleibt der neue aktive Knoten auch dann aktiv, wenn der ursprüngliche Knoten wieder online ist. Aufgrund synchroner WAL-Schreibvorgänge in den regionalen Log-Persistor kommt es beim Failover nicht zu Datenverlusten.
Das folgende Diagramm zeigt den Trafficfluss nach dem Failover.
Abbildung 2: Datenverkehr nach dem Failover.
Ein Failover erfolgt in der folgenden Ereignisabfolge:
- Der aktive Knoten oder die aktive Zone fällt aus. Das AlloyDB-System zur Zustandsüberwachung prüft regelmäßig, ob der aktive Knoten fehlerfrei ist. Wenn das System zur Zustandsüberwachung mehrere Prüfungen nicht besteht, wird ein Failover ausgelöst. Diese Erkennung kann bis zu 30 Sekunden dauern.
- Die Datenbank wird auf dem Standby-Knoten gestartet und nimmt Verbindungen an. Das dauert in der Regel weniger als 30 Sekunden.
- Der Stand-by-Knoten wird zum primären Knoten hochgestuft. Der neue primäre Knoten stellt Daten über die statische IP-Adresse der Instanz bereit und Clientabfragen sind nach einer erneuten Verbindung erfolgreich.
- AlloyDB erstellt einen Stand-by-Knoten in der zuvor aktiven Zone neu. Dieser Stand-by-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.
Hot-Standby-Architektur
AlloyDB-Instanzen mit PostgreSQL 18 bieten ein verbessertes Failover mit der Hot-Standby-Funktion.
Mit der Hot-Standby-Funktion führt AlloyDB den Standby-Knoten als Replikat aus. Während des Failovers kann dieses Replikat schneller in den Lese-/Schreibmodus wechseln, was die Ausfallzeit reduziert. Darüber hinaus ermöglicht die Replikation warme Caches, was nach einem Failover für eine konsistente Abfrageleistung sorgt.
Das folgende Diagramm zeigt die Hochverfügbarkeitsarchitektur mit dem Hot-Standby.
Abbildung 3: Hot-Standby.
Lesepools
Lesepoolinstanzen mit zwei oder mehr Knoten sind hochverfügbar. Knoten werden gleichmäßig auf Zonen verteilt, um die Ausfallsicherheit zu erhöhen. Bei Ausfällen wie einem Knoten- oder Zonenausfall leitet ein regionaler Load Balancer den Traffic an die verbleibenden fehlerfreien Knoten weiter, sodass es für Ihre Clients nicht zu Ausfallzeiten kommt.
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 pausiert und nach der Wiederherstellung der primären Instanz automatisch fortgesetzt.