In diesem Dokument werden direkte Hauptversionsupgrades für AlloyDB for PostgreSQL-Datenbanken beschrieben. Damit können Sie eine Datenbank auf eine höhere Version aktualisieren, ohne Daten zu migrieren oder die vorhandene Instanz zu ersetzen.
Die PostgreSQL-Community veröffentlicht regelmäßig neue Hauptversionen, die neue Funktionen, Leistungsverbesserungen und Sicherheitsverbesserungen enthalten. Nachdem PostgreSQL eine neue Hauptversion veröffentlicht hat, wird die kompatible Version in AlloyDB unterstützt. Um Ihre Datenbank auf dem neuesten Stand zu halten, können Sie ein Upgrade Ihres AlloyDB-Clusters auf eine höhere Hauptversion durchführen. Sie können Ihren Cluster mit dieser Funktion für die direkte Aktualisierung oder durch Migrieren Ihrer Daten zu einem neuen AlloyDB-Cluster aktualisieren.
Weitere Informationen finden Sie unter Richtlinien für Datenbankversionen.
Direkte Upgrades der Hauptversion sind aus folgenden Gründen eine effiziente Möglichkeit, die Hauptversion Ihres Clusters zu aktualisieren:
- AlloyDB behält Cluster- und Instanzdetails sowie Datenbankeinstellungen wie den Instanznamen, die IP-Adresse und Datenbankflags nach dem Upgrade bei.
- Sie müssen keine Anwendungsverbindungsstrings ändern.
- Alle Clusterinstanzen (primäre Instanz und Lesepool) werden im Rahmen desselben Vorgangs aktualisiert.
Workflow für das direkte Upgrade einer Hauptversion
Wenn Sie ein Upgrade für Ihren Cluster starten, führt AlloyDB die folgenden Aktionen aus:
- Führt Prüfungen vor dem Upgrade aus, um Inkompatibilitäten zu finden, die sich auf das Upgrade auswirken können.
- Bereitet das Upgrade auf die Hauptversion vor, einschließlich der Erstellung eines internen Klons des Clusters.
- Die primäre Instanz wird nicht mehr verfügbar sein. Die Ruhezeit beginnt. Lesevorgänge sind weiterhin über Lesepools möglich.
- Startet eine Sicherung vor dem Upgrade.
- Führt ein Upgrade der primären Instanz durch.
- Dadurch werden die Lesepoolinstanzen nicht mehr verfügbar.
- Macht die primäre Instanz verfügbar. Die Ruhezeit endet.
- Startet eine Sicherung nach dem Upgrade.
- Führt ein Upgrade von Lesepoolinstanzen durch.
Nachdem die Prüfungen vor dem Upgrade bestanden wurden, wird Ihr Cluster in einen internen Cluster im selben Projekt geklont. Die Sicherung und Wiederherstellung, die zum Klonen des Clusters erforderlich sind, dauern etwa 10 Minuten pro Terabyte an Daten.
Während des Klonvorgangs können Sie Ihren ursprünglichen Cluster weiterhin verwenden. Nach Abschluss des Klonvorgangs beginnt das Upgrade. Die primäre Instanz ist für Lese- und Schreibvorgänge nicht verfügbar, bis sie aktualisiert wurde. Die erwartete Ausfallzeit beträgt in der Regel 20 Minuten bis eine Stunde und hängt hauptsächlich von Ihrem Datenbankschema und der Anzahl der Objekte ab.
Nachdem die primäre Instanz aktualisiert wurde, sind Lesepoolinstanzen nicht mehr verfügbar. Upgrades werden gleichzeitig auf allen Lesepoolinstanzen versucht. Die Ausfallzeit wird voraussichtlich etwa 20 Minuten betragen.
Wenn das Upgrade der Hauptversion in einem Schritt vor dem Upgrade der primären Instanz fehlschlägt, werden alle Änderungen in AlloyDB automatisch rückgängig gemacht.
Nachdem die primäre Instanz aktualisiert wurde, wird die Clusterversion auf die Zielversion aktualisiert. Nach diesem Zeitpunkt werden bei Fehlern keine Rollbacks mehr ausgelöst. Beispielsweise führt AlloyDB kein Rollback des Clusters durch, wenn ein oder mehrere Upgrades von Lesepoolinstanzen fehlschlagen. Wenden Sie sich in diesen Fällen an den Google Cloud CLI-Support.
In der folgenden Tabelle finden Sie eine ungefähre Schätzung der Zeit, die für das Upgrade von Clustern mit unterschiedlichen Datenbankgrößen benötigt wird:
| Datenbankgröße | Vorzeitige Umstellung (keine Ausfallzeit) | Primäre Ausfallzeit | Ausfallzeiten von Lesepools | Gesamtdauer |
|---|---|---|---|---|
| 100 GB | ~ 15 Minuten | ~ 20 Minuten | ~ 20 Minuten | ~1 Stunde |
| 1 TB | ca. 30 Minuten | ~ 20 Minuten | ~ 20 Minuten | ~ 1 Stunde und 15 Minuten |
| 4 TB | ~1 Stunde | ~ 20 Minuten | ~ 20 Minuten | ~1 Stunde und 45 Minuten |
| 16 TB | ~3 Stunden | ~ 20 Minuten | ~ 20 Minuten | ca. 3 Stunden und 45 Minuten |
| 32 TB | ~5 Stunden, 30 Minuten | ~ 20 Minuten | ~ 20 Minuten | ~6 Stunden, 15 Minuten |
| 64 TB | ca. 11 Stunden | ~ 20 Minuten | ~ 20 Minuten | ca. 12 Stunden |
| 128 TB | ca. 21 Stunden und 30 Minuten | ~ 20 Minuten | ~ 20 Minuten | ~22 Stunden, 15 Minuten |
Weitere Informationen finden Sie unter Direktes Upgrade der Datenbank-Hauptversion durchführen.
Upgradestatus
Sie können den Status eines direkten Upgrades einer Hauptversion der Datenbank während der Ausführung überwachen.
Der Upgrade-Prozess umfasst die folgenden Phasen:
ALLOYDB_PRECHECKPG_UPGRADE_CHECKPREPARE_FOR_UPGRADEPRIMARY_INSTANCE_UPGRADEREAD_POOL_INSTANCES_UPGRADEROLLBACK(nur bei Fehlern vor dem Upgrade von Lesepools)CLEANUP
Die möglichen Status dieser Phasen sind:
NOT_STARTEDIN_PROGRESSSUCCESSFAILEDCANCEL_IN_PROGRESSCANCELLED
Kündigung von Upgrades
Sie können den Upgrade-Vorgang bis zu einem bestimmten Zeitpunkt während des Upgrades der primären Instanz abbrechen. Sobald dieser Punkt erreicht ist, können Sie ein Upgrade nicht mehr kündigen.
In der Google Cloud -Konsole kann der Vorgang nicht abgebrochen werden, wenn die Schaltfläche Upgrade abbrechen ausgegraut ist. Mit der Google Cloud CLI oder der REST API können Sie anhand von upgradeClusterStatus im Upgradestatus feststellen, ob Sie das Upgrade abbrechen können:
- Wenn
cancellabletrueist, können Sie das Upgrade abbrechen. - Wenn
cancellablefalseist oder im Status fehlt, können Sie das Upgrade nicht abbrechen.
Automatische Sicherungen vor und nach dem Upgrade
Wenn Sie ein Upgrade der Hauptversion durchführen, erstellt AlloyDB automatisch die folgenden fortlaufenden Sicherungen, wobei XX die Quellhauptversion und YY die Zielhauptversion ist.
- Die Sicherung vor dem Upgrade wird unmittelbar vor Beginn des Upgrades erstellt. Diese Sicherung wird mit dem Format
pre-upgrade-bkp-pgXX-pgYY-<uuid>benannt. Mit dieser Sicherung können Sie den Zustand vor dem Upgrade wiederherstellen. Die Wiederherstellung ist kein In-Place-Vorgang, sondern es wird ein neuer Cluster erstellt. - Die Sicherung nach dem Upgrade wird erstellt, nachdem die primäre Instanz aktualisiert wurde. Diese Sicherung wird mit dem Format
post-upgrade-bkp-pgXX-pgYY-<uuid>benannt.
Eine kontinuierliche Sicherung ist inkrementell. Das bedeutet, dass in der Sicherung nur die Daten gespeichert werden, die sich im Vergleich zur vorherigen kontinuierlichen Sicherung geändert haben. Dadurch werden die Größe und die Kosten (in Ressourcen) des Back-ups reduziert und die Erstellung des Back-ups beschleunigt. Weitere Informationen finden Sie unter Datensicherung und ‑wiederherstellung – Übersicht.
Wenn Sie die Liste Ihrer Sicherungen aufrufen, werden die Upgradesicherungen vom Typ CONTINUOUS aufgelistet. Weitere Informationen finden Sie unter Liste der Sicherungen ansehen.
Für die Wiederherstellung zu einem bestimmten Zeitpunkt (Point-In-Time Recovery, PITR) muss eine Sicherung einer Version verfügbar sein. Die Wiederherstellung ist im aktualisierten Cluster erst verfügbar, wenn die Sicherung nach dem Upgrade oder eine andere Sicherung, die nach dem Upgrade der primären Instanz gestartet wird, abgeschlossen ist.