Direktes Upgrade der Datenbankhauptversion

In diesem Dokument werden direkte Upgrades der Hauptversion von AlloyDB for PostgreSQL-Datenbanken beschrieben. Mit diesen Upgrades 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, fügt AlloyDB Unterstützung für die kompatible Version hinzu. Damit Ihre Datenbank auf dem neuesten Stand bleibt, können Sie ein Upgrade Ihres AlloyDB-Clusters auf eine höhere Hauptversion durchführen. Sie können Ihren Cluster mit dieser direkten Upgradefunktion aktualisieren oder Ihre Daten zu einem neuen AlloyDB-Cluster migrieren.

Weitere Informationen finden Sie in den 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 nach dem Upgrade Cluster- und Instanzdetails sowie Datenbankeinstellungen wie den Instanznamen, die IP-Adresse und Datenbank-Flags bei.
  • Sie müssen keine Anwendungsverbindungsstrings ändern.
  • Alle Clusterinstanzen (primär und Lesepool) werden im Rahmen desselben Vorgangs aktualisiert.

Außerdem werden Rollenmitgliedschaften mit nicht vorhandenen Gewährern (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 direkte Upgrades der Hauptversion

Wenn Sie ein Upgrade für Ihren Cluster starten, führt AlloyDB die folgenden Aktionen aus:

  1. Führt Prüfungen vor dem Upgrade aus, um Inkompatibilitäten zu finden, die sich auf das Upgrade auswirken können.
  2. Bereitet das Upgrade der Hauptversion vor, einschließlich der Erstellung eines internen Klons des Clusters.
  3. Macht die primäre Instanz nicht verfügbar. Die Ausfallzeit beginnt. Lesevorgänge sind weiterhin über Lesepools möglich.
  4. Startet eine Sicherung vor dem Upgrade.
  5. Führt ein Upgrade der primären Instanz durch.
  6. Macht die Lesepoolinstanzen nicht verfügbar.
  7. Macht die primäre Instanz verfügbar. Die Ausfallzeit endet.
  8. Startet eine Sicherung nach dem Upgrade.
  9. Führt ein Upgrade der Lesepoolinstanzen durch.

Wenn die Prüfungen vor dem Upgrade erfolgreich sind, wird Ihr Cluster in einen internen Cluster im selben Projekt geklont. Die für das Klonen des Clusters erforderliche Sicherung und Wiederherstellung dauert etwa 10 Minuten pro Terabyte Daten.

Während des Klonvorgangs können Sie Ihren ursprünglichen Cluster weiterhin verwenden. Nach Abschluss des Klonvorgangs beginnt der Upgradevorgang. Die primäre Instanz ist für Lese- und Schreibvorgänge nicht verfügbar, bis das Upgrade der primären Instanz abgeschlossen ist. 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 die Lesepoolinstanzen nicht mehr verfügbar. Upgrades werden gleichzeitig für alle Lesepoolinstanzen versucht. Die Ausfallzeit beträgt voraussichtlich etwa 20 Minuten.

Wenn das Upgrade der Hauptversion in einem Schritt fehlschlägt, bevor das Upgrade der primären Instanz durchgeführt wird, führt AlloyDB automatisch ein Rollback aller Änderungen durch.

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 das Upgrade einer oder mehrerer Lesepoolinstanzen fehlschlägt. 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 Vor dem Upgrade (keine Ausfallzeit) Ausfallzeit der primären Instanz Ausfallzeit des Lesepools Gesamtdauer
100 GB ~15 Minuten ~20 Minuten ~20 Minuten ~1 Stunde
1 TB ~30 Minuten ~20 Minuten ~20 Minuten ~1 Stunde 15 Minuten
4 TB ~1 Stunde ~20 Minuten ~20 Minuten ~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 ~11 Stunden ~20 Minuten ~20 Minuten ~12 Stunden
128 TB ~21 Stunden 30 Minuten ~20 Minuten ~20 Minuten ~22 Stunden 15 Minuten

Weitere Informationen finden Sie unter Direkte Aktualisierung der Hauptversion einer Datenbank durchführen.

Upgrade status

Sie können den Status eines direkten Upgrades der Hauptversion einer Datenbank während des Vorgangs beobachten.

Der Upgradevorgang umfasst die folgenden Phasen:

  • ALLOYDB_PRECHECK
  • PG_UPGRADE_CHECK
  • PREPARE_FOR_UPGRADE
  • PRIMARY_INSTANCE_UPGRADE
  • READ_POOL_INSTANCES_UPGRADE
  • ROLLBACK(nur bei Fehlern vor Upgrades des Lesepools)
  • CLEANUP

Die möglichen Status dieser Phasen sind:

  • NOT_STARTED
  • IN_PROGRESS
  • SUCCESS
  • FAILED
  • CANCEL_IN_PROGRESS
  • CANCELLED

Upgrade abbrechen

Sie können den Upgradevorgang bis zu einem bestimmten Zeitpunkt während des Upgrades der primären Instanz abbrechen. Sobald dieser Zeitpunkt überschritten ist, können Sie das 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 prüfen, ob Sie das Upgrade abbrechen können, indem Sie upgradeClusterStatus im Upgradestatus prüfen:

  • Wenn cancellable den Wert true hat, können Sie das Upgrade abbrechen.
  • Wenn cancellable den Wert false hat 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 einen neuen Cluster erstellt.
  • Die Sicherung nach dem Upgrade wird erstellt, nachdem das Upgrade der primären Instanz durchgeführt 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 die Erstellung der Sicherung. Weitere Informationen finden Sie unter Daten sichern und wiederherstellen – Ü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, nachdem die Sicherung nach dem Upgrade oder eine andere Sicherung, die nach dem Upgrade der primären Instanz gestartet wird, abgeschlossen ist.

Nächste Schritte