Wenn Sie neue PostgreSQL-Funktionen, Leistungsverbesserungen und Sicherheitsverbesserungen übernehmen möchten, ohne Daten zu migrieren oder Verbindungsstrings für Anwendungen zu ändern, können Sie ein direktes Upgrade der Hauptversion für Ihren AlloyDB for PostgreSQL-Cluster durchführen.
Die PostgreSQL-Community veröffentlicht regelmäßig neue Hauptversionen, die neue Features, Leistungsverbesserungen und Sicherheitsverbesserungen enthalten. Nachdem PostgreSQL eine neue Hauptversion veröffentlicht hat, fügt AlloyDB Unterstützung für die kompatible Version hinzu. Wenn Sie Ihre Datenbank auf dem neuesten Stand halten möchten, 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 ein direktes Upgrade aktualisieren oder Ihre Daten zu einem neuen AlloyDB-Cluster migrieren.
Weitere Informationen finden Sie unter Richtlinien für Datenbankversionen.
Direkte Upgrades von Hauptversionen sind aus folgenden Gründen eine effiziente Möglichkeit, ein Upgrade der Hauptversion Ihres Clusters durchzuführen:
- AlloyDB behält nach dem Upgrade die Cluster- und Instanzdetails sowie die Datenbankeinstellungen wie den Instanznamen, die IP-Adresse und die Datenbank-Flags bei.
- Sie müssen keine Anwendungsverbindungsstrings ändern.
- Alle Clusterinstanzen (primärer und Lesepool) werden im Rahmen desselben Vorgangs aktualisiert.
Außerdem werden Rollenmitgliedschaften mit nicht vorhandenen Erteilern (verwaiste Mitgliedschaften) nicht beibehalten. Wenn ein Cluster verwaiste Mitgliedschaften im Katalog pg_auth_members enthält, gehen diese Rollenmitgliedschaften nach dem Upgrade verloren. Weitere Informationen finden Sie unter Cluster auf ein Upgrade der Hauptversion vorbereiten.
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 des Erstellens eines internen Klons des Clusters.
- Macht die primäre Instanz nicht verfügbar. Die Ruhezeit beginnt. Lesevorgänge können weiterhin über Lesepools ausgeführt werden.
- Initiiert eine Sicherung vor dem Upgrade.
- Führt ein Upgrade der primären Instanz durch.
- Macht die Lesepoolinstanzen nicht verfügbar.
- Macht die primäre Instanz verfügbar. Die Ruhezeit endet.
- Initiiert 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. Das Sichern und Wiederherstellen, das zum Klonen des Clusters erforderlich ist, dauert etwa 10 Minuten pro Terabyte Daten.
Während des Klonvorgangs können Sie den ursprünglichen Cluster weiterhin verwenden. Nach Abschluss des Klonvorgangs beginnt der Upgradeprozess. Die primäre Instanz ist sowohl für Lese- als auch für 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.
Nach dem Upgrade der primären Instanz sind Lesepoolinstanzen nicht mehr verfügbar. Upgrades werden für alle Lesepoolinstanzen gleichzeitig versucht. Die Ausfallzeit beträgt voraussichtlich etwa 20 Minuten.
Wenn das Upgrade der Hauptversion bei einem Schritt vor dem Upgrade der primären Instanz fehlschlägt, werden alle Änderungen von AlloyDB automatisch rückgängig gemacht.
Nach dem Upgrade der primären Instanz wird die Clusterversion auf die Zielversion aktualisiert. Nach diesem Zeitpunkt werden bei Fehlern keine Rollbacks mehr ausgelöst. AlloyDB führt beispielsweise kein Rollback des Clusters durch, wenn ein oder mehrere Upgrades von Lesepoolinstanzen fehlschlagen. Wenden Sie sich in diesen Fällen an den Google Cloud Support.
Die folgende Tabelle enthält 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 | Ausfallzeit des Lesepools | Gesamtdauer |
|---|---|---|---|---|
| 100 GB | ~15 Minuten | ~20 Minuten | ~20 Minuten | ~1 Stunde |
| 1 TB | ca. 30 Minuten | ~20 Minuten | ~20 Minuten | ~1 Stunde, 15 Minuten |
| 4 TB | ~1 Stunde | ~20 Minuten | ~20 Minuten | ca. 1 Stunde, 45 Minuten |
| 16 TB | ~3 Stunden | ~20 Minuten | ~20 Minuten | ~3 Stunden, 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 | ~12 Stunden |
| 128 TB | ca. 21 Stunden, 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 der Hauptversion der Datenbank überwachen, während es ausgeführt wird.
Der Upgradeprozess 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ündigungen nach Upgrades
Sie können den Upgradevorgang bis zu einem bestimmten Zeitpunkt während des Upgrades der primären Instanz abbrechen. Danach können Sie ein Upgrade nicht mehr abbrechen.
In der Google Cloud Console 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 feststellen, ob Sie das Upgrade abbrechen können. Prüfen Sie dazu upgradeClusterStatus im Upgradestatus:
- Wenn
cancellableden Werttruehat, können Sie das Upgrade abbrechen. - Wenn
cancellableden Wertfalsehat 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 kontinuierlichen Sicherungen, wobei XX die Hauptversion der Quelle und YY die Hauptversion des Ziels ist.
- Die Sicherung vor dem Upgrade wird unmittelbar vor Beginn des Upgrades erstellt. Diese Sicherung wird im Format
pre-upgrade-bkp-pgXX-pgYY-<uuid>benannt. Mit dieser Sicherung können Sie den Zustand vor dem Upgrade wiederherstellen. Beachten Sie, dass die Wiederherstellung kein direkter Vorgang ist und ein neuer Cluster erstellt wird. - Die Sicherung nach dem Upgrade wird erstellt, nachdem die primäre Instanz aktualisiert wurde. Diese Sicherung wird im 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. Dieser Ansatz reduziert die Größe und die Kosten (in Ressourcen) der Sicherung und beschleunigt den Prozess der Sicherungserstellung. 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.