Direktes Upgrade der Datenbankhauptversion durchführen

Auf dieser Seite wird beschrieben, wie Sie ein direktes Upgrade der Hauptversion einer AlloyDB for PostgreSQL-Datenbank durchführen. Informationen zu Anwendungsfällen, Workflow und automatischen Sicherungen für das In-Place-Upgrade der Datenbankhauptversion finden Sie unter Übersicht über das In-Place-Upgrade der Datenbankhauptversion.

Upgrade einer Hauptdatenbankversion planen

So planen Sie ein Upgrade einer Hauptversion der Datenbank:

1. Suchen Sie nach der aktuellen Hauptversion Ihrer Datenbank.

   Console

   1. Rufen Sie in der Google Cloud Console die Seite Cluster auf.

      Zu den Clustern

   2. Wählen Sie einen Cluster aus der Liste aus. Die Seite Übersicht wird angezeigt.

   3. Suchen Sie im Feld Version nach der Hauptversion der Datenbank.

   gcloud

   Informationen zur Installation und den ersten Schritten mit der gcloud CLI finden Sie unter gcloud CLI installieren. Informationen zum Starten von Cloud Shell finden Sie unter Cloud Shell verwenden.

   Führen Sie den folgenden Befehl aus, um die Clusterdetails abzurufen, einschließlich der aktuellen Hauptversion:

   gcloud alloydb clusters describe CLUSTER_ID --region=REGION

   Ersetzen Sie die folgenden Werte:

   • CLUSTER_ID: die Cluster-ID
   • REGION: Der Clusterstandort oder die Clusterregion.

   REST v1beta

   Führen Sie die folgende Anfrage aus, um die Clusterdetails einschließlich der aktuellen Hauptversion abzurufen:

   GET https://alloydb.googleapis.com/v1beta/projects/PROJECT_ID/locations/REGION/clusters/CLUSTER_ID

   Ersetzen Sie die folgenden Werte:

   • CLUSTER_ID: die Cluster-ID
   • PROJECT_ID: die Projekt-ID
   • REGION: Der Clusterstandort oder die Clusterregion.

   Wenn Sie die Anfrage senden möchten, verwenden Sie eine der folgenden Optionen:

   curl (Linux, macOS oder Cloud Shell)

   Führen Sie folgenden Befehl aus:

      curl -X GET \
            -H "Authorization: Bearer $(gcloud auth print-access-token)" \
            -H "Content-Type: application/json; charset=utf-8" \
            "https://alloydb.googleapis.com/v1beta/projects/PROJECT_ID/locations/REGION/clusters/CLUSTER_ID"
      

   PowerShell (Windows)

   Führen Sie dazu diesen Befehl aus:

      $cred = gcloud auth print-access-token
      $headers = @{ "Authorization" = "Bearer $cred" }
   
      Invoke-WebRequest `
        -Method GET `
        -Headers $headers `
        -Uri "https://alloydb.googleapis.com/v1beta/projects/PROJECT_ID/locations/REGION/clusters/CLUSTER_ID| Select-Object -Expand Content
      

2. Suchen Sie in der folgenden Tabelle nach einer Ziel-Hauptversion der Datenbank. Eine vollständige Liste der von AlloyDB unterstützten Datenbankversionen finden Sie unter Datenbankversionen und Versionsrichtlinien.

   Hauptversion der Quelle	Unterstützte Zielhauptversion(en)
   POSTGRES_14	POSTGRES_15 POSTGRES_16
   POSTGRES_15	POSTGRES_16

3. Sehen Sie sich die Funktionen an, die in den einzelnen Hauptversionen der Datenbank angeboten werden.

   • PostgreSQL 16
   • PostgreSQL 15
   • PostgreSQL 14

4. Ermitteln Sie alle Inkompatibilitäten, die Sie beheben müssen. Neue Hauptversionen können inkompatible Änderungen einführen, sodass Sie möglicherweise den Anwendungscode, das Schema oder die Datenbankeinstellungen ändern müssen.

5. Bevor Sie das Upgrade der Hauptversion für Ihren Produktionscluster starten, empfehlen wir Ihnen, Ihren Cluster zu klonen und das Upgrade der Hauptversion für den geklonten Cluster zu testen.

   Überprüfen Sie nicht nur, ob das Upgrade erfolgreich abgeschlossen wurde, sondern führen Sie auch Tests durch, um sicherzustellen, dass sich die Anwendung auf dem aktualisierten Cluster wie erwartet verhält.

Cluster für ein Upgrade auf eine Hauptversion vorbereiten

Verwenden Sie eine der folgenden Optionen, um eine Verbindung zur Datenbank herzustellen:

• AlloyDB Studio
• psql
• Andere Verbindungsmethoden

1. Regionenübergreifende Replikate löschen oder hochstufen Direkte Hauptversionsupgrades von Datenbanken unterstützen keine regionenübergreifenden Replikate. Weitere Informationen finden Sie unter Regionenübergreifende Replikation.

2. Wenn Ihr AlloyDB-Cluster eine logische Replikationsquelle ist, deaktivieren Sie die Downstream-Abos und löschen Sie alle Slots für die logische Replikation. Sie können die Abos wieder aktivieren und die logischen Replikations-Slots nach dem Upgrade neu erstellen. Wenn die AlloyDB-Instanz nur ein logisches Replikationsziel ist, sind diese Schritte nicht erforderlich. So deaktivieren Sie Abos und löschen logische Replikations-Slots:

   1. Deaktivieren Sie jedes Downstream-Abo auf dem Abonnenten oder dem Downstream-Replikationsziel. Deaktivieren Sie die Downstream-Abos nicht für die AlloyDB-Instanz, für die ein Upgrade durchgeführt wird:

      • Wenn Sie pglogical verwenden, führen Sie den folgenden Befehl aus:

        SELECT * FROM
        pglogical.alter_subscription_disable(SUBSCRIPTION_NAME, immediate);
        

        Ersetzen Sie SUBSCRIPTION_NAME in der Abfrage durch den Namen des vorhandenen Abos. Wenn das Abo sofort deaktiviert werden muss, setzen Sie den Wert des Parameters immediate auf true. Standardmäßig ist der Wert false und das Abo wird erst deaktiviert, wenn die aktuelle Transaktion endet.

        Beispiel:

        postgres=> SELECT * FROM pglogical.alter_subscription_disable('test_sub',true);
        alter_subscription_disable
        ----------------------------
        t
        (1 row)
        

      • Wenn Sie eine andere Erweiterung als pglogical verwenden, führen Sie den folgenden Befehl aus:

        ALTER SUBSCRIPTION SUBSCRIPTION_NAME DISABLE;
        

   2. Löschen Sie alle logischen Replikationsslots auf der primären AlloyDB-Instanz mit dem folgenden Befehl:

      SELECT pg_drop_replication_slot(REPLICATION_SLOT_NAME) FROM pg_replication_slots WHERE slot_type = 'logical';
      

      Ersetzen Sie REPLICATION_SLOT_NAME in der Abfrage durch den Namen des Replikations-Slots.

3. Verwalten Sie Ihre PostgreSQL-Erweiterungen. Weitere Informationen finden Sie unter Datenbankerweiterungen konfigurieren.

   Bei der Prüfung vor dem Upgrade werden Inkompatibilitäten von Erweiterungen erkannt und diese Verstöße werden zusammen mit Vorschlägen für Maßnahmen in den Logs angezeigt. Weitere Informationen finden Sie unter Fehler bei der Prüfung vor dem Upgrade ansehen.

   Möglicherweise müssen Sie Folgendes tun:

   1. Löschen Sie alle Erweiterungen, die in der Zielversion nicht mehr unterstützt werden.

   2. Aktualisieren Sie PostGIS und die zugehörigen Erweiterungen (address_standardizer, address_standardizer_data_us, postgis_raster, postgis_sfcgal, postgis_tiger_geocoder und postgis_topology) auf eine unterstützte Version in der Ziel-PostgreSQL-Version. Weitere Informationen finden Sie unter PostGIS-Erweiterungen. In der folgenden Tabelle sind die mindestens unterstützten PostGIS-Erweiterungsversionen für jede PostgreSQL-Hauptversion aufgeführt:

      PostgreSQL-Version	Unterstützte Mindestversion von PostGIS
      PG14	3.1
      PG15	3.2
      PG16	3.4

      Wenn Ihre PostGIS-Version beispielsweise 3.1.x ist und Sie ein Upgrade von POSTGRES 14 auf POSTGRES 16 durchführen möchten, verwenden Sie den folgenden Befehl, um die PostGIS-Erweiterung zu aktualisieren:

      ALTER EXTENSION postgis UPDATE TO '3.4.0';
      SELECT PostGIS_Version();
      

4. Prüfen Sie, ob Verbindungen für jede Datenbank außer template0 zulässig sind. Führen Sie dazu die folgende Abfrage aus und prüfen Sie das Feld datallowconn für jede Datenbank:

   SELECT datname,datallowconn from pg_database;
   

   Der Wert t im Feld datallowconn bedeutet, dass die Verbindung zulässig ist. Der Wert f gibt an, dass keine Verbindung hergestellt werden kann. Die Datenbank template0 darf keine Verbindungen zulassen.

   Führen Sie den folgenden Befehl aus, um Verbindungen zu einer Datenbank zuzulassen:

   ALTER DATABASE DATABASE_NAME WITH ALLOW_CONNECTIONS = true;
   

5. Prüfen Sie mit dem folgenden Befehl, ob template1 eine Vorlagendatenbank ist:

   SELECT datname, datistemplate FROM pg_database WHERE datname = 'template1';
   

   Wenn datistemplate f ist, legen Sie es mit dem folgenden Befehl auf true fest:

   ALTER DATABASE template1 WITH IS_TEMPLATE true;
   

Direktes Upgrade der Hauptversion des Clusters durchführen

Das direkte Upgrade der Hauptversion der Datenbank kann je nach Faktoren wie Datenbankgröße, Schemagröße und Anzahl der Lesepoolinstanzen im Cluster zwischen 40 Minuten und 48 Stunden dauern. Die Ausfallzeit der primären Instanz beträgt in der Regel 20 Minuten bis eine Stunde und hängt hauptsächlich von Ihrem Datenbankschema ab.

Wenn Sie eine direkte Upgradeanfrage für die Hauptversion stellen, führt AlloyDB zuerst Prüfungen vor dem Upgrade durch. Wenn AlloyDB feststellt, dass Ihr Cluster nicht für ein Upgrade auf eine Hauptversion bereit ist, schlägt die Anfrage fehl. Weitere Informationen finden Sie unter Fehlerbehebung bei einem direkten Hauptversionsupgrade.

So führen Sie ein direktes Upgrade der Hauptdatenbankversion durch:

gcloud alloydb clusters upgrade CLUSTER_ID --region=REGION --version=DATABASE_VERSION --async

gcloud alloydb clusters upgrade my-cluster --region=us-central1 --version=POSTGRES_16 --async

PATCH https://alloydb.googleapis.com/v1beta/projects/PROJECT_ID/locations/REGION/clusters/CLUSTER_ID:upgrade

{
  "version": "DATABASE_VERSION"
}

{
"version": "POSTGRES_16"
}

resource "google_alloydb_instance" "default" {
cluster       = google_alloydb_cluster.default.name
instance_id   = "alloydb-instance"
instance_type = "PRIMARY"

machine_config {
  cpu_count = 2
}

depends_on = [google_service_networking_connection.vpc_connection]
}

resource "google_alloydb_cluster" "default" {
  cluster_id = "alloydb-cluster"
  location   = "us-central1"
  network_config {
    network = google_compute_network.default.id
  }
  database_version = "POSTGRES_16"

  initial_user {
    password = "alloydb-cluster"
  }
}

data "google_project" "project" {}

resource "google_compute_network" "default" {
  name = "alloydb-network"
}

resource "google_compute_global_address" "private_ip_alloc" {
  name          =  "alloydb-cluster"
  address_type  = "INTERNAL"
  purpose       = "VPC_PEERING"
  prefix_length = 16
  network       = google_compute_network.default.id
}

resource "google_service_networking_connection" "vpc_connection" {
  network                 = google_compute_network.default.id
  service                 = "servicenetworking.googleapis.com"
  reserved_peering_ranges = [google_compute_global_address.private_ip_alloc.name]
}

Upgrade der Hauptversion des Clusters überwachen

Nachdem das In-Place-Upgrade der Hauptdatenbankversion gestartet wurde, können Sie den Upgradestatus über die Google Cloud Console, die gcloud CLI oder die REST API überwachen.

Antwort auf Upgradevorgang

Die Antwort auf den Vorgang UpgradeCluster enthält Folgendes:

• status: Status des gesamten Upgradevorgangs. Mögliche Werte sind SUCCESS, FAILED und PARTIAL_SUCCESS..
• message: Bietet eine kurze Zusammenfassung des Ergebnisses des Upgradevorgangs.
• clusterUpgradeDetails: Upgrade-Details für die Cluster, die aktualisiert werden. Dieses Feld ist ein Array. AlloyDB lässt nur ein einzelnes Cluster-Upgrade zu, daher ist nur ein Eintrag enthalten.
  • name: Vollständig qualifizierter Name des Clusters.
  • upgradeStatus: Der Status des Cluster-Upgrades. Mögliche Werte sind SUCCESS, FAILED und PARTIAL_SUCCESS. PARTIAL_SUCCESS bedeutet, dass für mindestens eine Lesepoolinstanz kein Upgrade durchgeführt werden kann.
  • clusterType: Der Clustertyp. Mit AlloyDB können Sie nur ein einzelnes PRIMARY-Cluster aktualisieren. Dieser Typ muss immer PRIMARY sein.
  • databaseVersion: die aktuelle Datenbankversion des Clusters.
  • stageInfo: Informationen zu den wichtigsten Upgradestufen.
    • status: SUCCESS oder FAILED
    • logs_url: Link zu den von der Phase generierten Logs. Leer für Phasen, in denen keine Logs generiert werden.
  • instanceUpgradeDetails: Upgrade-Informationen für alle Instanzen im Cluster.
    • name: Voll qualifizierter Name der Instanz.
    • upgradeStatus: SUCCESS oder FAILED
    • instanceType: PRIMARY oder READ_POOL

Hier ist ein Beispiel für eine Antwort auf einen Upgrade-Vorgang:

"response": {
  "@type": "type.googleapis.com/google.cloud.alloydb.v1alpha.UpgradeClusterResponse",
  "status": "SUCCESS",
  "message": "Cluster upgraded successfully.",
  "clusterUpgradeDetails": [
    {
      "name": "projects/1234/locations/us-central1/clusters/abc",
      "upgradeStatus": "SUCCESS",
      "clusterType": "PRIMARY",
      "databaseVersion": "POSTGRES_16",
      "stageInfo": [
        {
          "stage": "ALLOYDB_PRECHECK",
          "status": "SUCCESS",
          "logsUrl": "https://console.cloud.google.com/logs/query..."
        },
        {
          "stage": "PG_UPGRADE_CHECK",
          "status": "SUCCESS",
          "logsUrl": "https://console.cloud.google.com/logs/query..."
        },
        {
          "stage": "PRIMARY_INSTANCE_UPGRADE",
          "status": "SUCCESS",
          "logsUrl": "https://console.cloud.google.com/logs/query..."
        },
        {
          "stage": "READ_POOL_INSTANCES_UPGRADE",
          "status": "SUCCESS",
        }
      ],
      "instanceUpgradeDetails": [
        {
          "name": "projects/1234/locations/us-central1/clusters/abc/instances/primary",
          "upgradeStatus": "SUCCESS",
          "instanceType": "PRIMARY",
        },
        {
          "name": "projects/1234/locations/us-central1/clusters/abc/instances/read1",
          "upgradeStatus": "SUCCESS",
          "instanceType": "READ_POOL",
        },
        {
          "name": "projects/1234/locations/us-central1/clusters/abc/instances/read2",
          "upgradeStatus": "SUCCESS",
          "instanceType": "READ_POOL",
        }
      ]
    }
  ]
}

AlloyDB-Upgradelogs ansehen

AlloyDB veröffentlicht alle Upgrade-Logs im Lognamen postgres_upgrade.

So rufen Sie Logs zum Upgrade auf:

1. Rufen Sie in der Google Cloud Console die Seite Log-Explorer auf:

   Zum Log-Explorer

   Wenn Sie diese Seite über die Suchleiste suchen, wählen Sie das Ergebnis aus, dessen Zwischenüberschrift Logging ist.

2. Wählen Sie alloydb.googleapis.com/postgres_upgrade als Lognamen aus. Das entspricht der Abfrage "logName="projects/PROJECT_ID/logs/alloydb.googleapis.com%2Fpostgres_upgrade".

3. Verwenden Sie die folgenden Labels, um die Logs zu filtern:

   Label	Beschreibung
   LOG_TYPE	Die Upgradephase, in der das Log generiert wurde. Mögliche Werte sind ALLOYDB_PRECHECK, PG_UPGRADE_CHECK und PG_UPGRADE.
   OPERATION_NAME	Vollständiger Name des Upgradevorgangs.
   FILE_NAME	Wird nur für pg_upgrade_check- und pg_upgrade-Logs ausgefüllt und entspricht den Logdateien, die vom pg_upgrade-Dienstprogramm generiert werden.

Im Folgenden finden Sie ein Beispiel für eine Abfrage, die AlloyDB-Vorabprüfungs-Upgrade-Logs für einen bestimmten Vorgang zurückgibt:

logName="projects/project1234/logs/alloydb.googleapis.com%2Fpostgres_upgrade"
labels.LOG_TYPE="ALLOYDB_PRECHECK"
labels.OPERATION_NAME="projects/PROJECT_ID/locations/REGION/operations/OPERATION_ID"

Weitere Informationen zu Upgrade-Prüfungen finden Sie unter Direktes Upgrade der Datenbank-Hauptversion – Übersicht.

Upgradelogs für einen Cluster ansehen

So rufen Sie die Upgradeprotokolle für einen Cluster auf, wenn Sie die Vorgangs-ID nicht kennen und der Vorgang abgelaufen ist:

1. Rufen Sie in der Google Cloud Console die Seite Log-Explorer auf:

   Zum Log-Explorer

   Wenn Sie diese Seite über die Suchleiste suchen, wählen Sie das Ergebnis aus, dessen Zwischenüberschrift Logging ist.

2. Führen Sie eine Abfrage für die AlloyDB-Pre-Check-Logs für Ihren Cluster aus.

   logName="projects/PROJECT_ID/logs/alloydb.googleapis.com%2Fpostgres_upgrade"
   labels.LOG_TYPE="ALLOYDB_PRECHECK"
   resource.labels.cluster_id=CLUSTER_ID
   

3. Suchen Sie anhand des Loglabels OPERATION_NAME nach dem Operation_ID.

   Im folgenden Beispiel ist Operation_ID aus OPERATION_NAME operation-1728225968201-623cff6ed1e02-e34b7191-3cd92013.

   labels.OPERATION_NAME="projects/myproject/locations/us-central1/operations/operation-1728225968201-623cff6ed1e02-e34b7191-3cd92013"
   

4. Alle postgres_upgrade-Logs für einen bestimmten Vorgang abfragen.

   logName="projects/production-1/logs/alloydb.googleapis.com%2Fpostgres_upgrade"
   labels.OPERATION_NAME="operation-1728225968201-623cff6ed1e02-e34b7191-3cd92013"
   

Direktes Upgrade der Datenbank-Hauptversion abbrechen

Sie können einen laufenden Vorgang zum Upgrade auf eine neue Hauptversion über die Google Cloud Console, die gcloud CLI oder die REST API abbrechen.

Vorgangs-ID ermitteln

Wenn Sie den Vorgang zum Upgrade der Hauptversion mit der gcloud CLI oder der REST API abbrechen möchten, benötigen Sie die Vorgangs-ID. Sie müssen diese ID im gcloud CLI- oder REST API-Befehl angeben, damit AlloyDB weiß, welcher Vorgang abgebrochen werden soll.

Sie können das Upgrade nicht mehr abbrechen, nachdem das Upgrade der primären Instanz einen bestimmten Punkt erreicht hat.

Wenn Sie das direkte Upgrade der Hauptversion starten, wird die Vorgangs-ID im Feld name der Antwort zurückgegeben. Beispielantwort

Sie können die Vorgangs-ID auch durch einen operations.list-Aufruf auf dem AlloyDB-Cluster ermitteln.

Upgrade abbrechen

So brechen Sie ein In-Place-Upgrade auf eine neue Hauptversion ab:

gcloud alloydb operations cancel OPERATION_ID

POST https://alloydb.googleapis.com/v1beta/projects/PROJECT_ID/operations/OPERATION_ID:cancel

       curl -X POST \
             -H "Authorization: Bearer $(gcloud auth print-access-token)" \
             -H "Content-Type: application/json; charset=utf-8" \
             -d "" \
            "https://alloydb.googleapis.com/v1/projects/PROJECT_ID/operations/OPERATION_ID:cancel"
  

       $cred = gcloud auth print-access-token
       $headers = @{ "Authorization" = "Bearer $cred" }

       Invoke-WebRequest `
         -Method POST `
         -Headers $headers `
         -Uri "https://alloydb.googleapis.com/v1beta/projects/PROJECT_ID/operations/OPERATION_ID:cancel"| Select-Object -Expand Content
    

Direktes Upgrade der Hauptversion abschließen

Um das Upgrade der Hauptversion abzuschließen, stellen Sie mit AlloyDB Studio, psql oder anderen Verbindungsmethoden eine Verbindung zu einer AlloyDB-Instanz her.

Wenn Sie ein anderes System als AlloyDB verwenden, finden Sie in der Systemdokumentation eine Anleitung zum Herstellen einer Verbindung.

Führen Sie nach dem Upgrade Ihres Clusters die folgenden Schritte aus, um das Upgrade abzuschließen:

1. Wenn Sie die pglogical-Replikation zuvor deaktiviert haben, aktivieren Sie sie wieder.pglogical Wenn Sie die pglogical-Replikation aktivieren, wird automatisch der erforderliche Replikations-Slot erstellt.

   1. Löschen Sie das Abo pglogical auf dem Zielreplikat mit dem folgenden Befehl:

        select pglogical.drop_subscription(subscription_name name);
      

      Ersetzen Sie name durch den Namen des vorhandenen Abos. Beispiel:

      postgres=> select pglogical.drop_subscription(subscription_name:= 'test_sub');
      -[ RECORD 1 ]-----+--
      drop_subscription |1
      
      1.  Recreate the `pglogical` subscription on the destination or
        replica by providing the following connection information to the
        AlloyDB primary instance:
      
        ```sql
        SELECT pglogical.create_subscription(
        subscription_name :='test_sub',<br>
        provider_dsn := 'host=primary-ip port=5432 dbname=postgres user=replication_user password=replicapassword'
        );
        ```
      
      1.  Check the status of the subscription by using the following command:
      
        ```sql
        SELECT * FROM pglogical.show_subscription_status('test_sub');
        ```
      
      1.  Test the replication by performing write transactions and
        verifying that the changes are visible on the destination.
      

2. Aktualisieren Sie die Datenbankstatistiken.

   Führen Sie nach Abschluss des Upgrades ANALYZE auf Ihrem primären Cluster aus, um die Systemstatistiken zu aktualisieren. Genaue Statistiken sorgen dafür, dass der PostgreSQL-Abfrageplaner Abfragen optimal verarbeitet. Fehlende Statistiken können zu ungenauen Abfrageplänen führen, die wiederum die Leistung beeinträchtigen und zu viel Arbeitsspeicher belegen können.

3. Führen Sie Akzeptanztests durch, um zu prüfen, ob das aktualisierte System wie erwartet funktioniert.

4. Prüfen Sie, ob die Hauptversion der aktualisierten Datenbank auf der Seite Übersicht des Clusters in der Google Cloud Console angezeigt wird.

Wiederherstellung der vorherigen Hauptversion

Wenn das aktualisierte Datenbanksystem nicht wie erwartet funktioniert, müssen Sie möglicherweise zum Zustand vor dem Upgrade zurückkehren. Dazu stellen Sie eine Sicherung vor dem Upgrade wieder her. Das kann entweder die Sicherung sein, die AlloyDB automatisch während des Upgrades erstellt, oder eine vorhandene Sicherung vor dem Upgrade. So erstellen Sie einen neuen Cluster mit dem Zustand vor dem Upgrade.

So stellen Sie den Zustand vor dem Upgrade wieder her:

1. Ermitteln Sie eine Sicherung vor dem Upgrade, aus der Sie die Daten wiederherstellen möchten. Während des Upgrades erstellt AlloyDB automatisch eine Sicherung vor dem Upgrade mit dem Präfix pre-upgrade-bkp. Weitere Informationen finden Sie unter Liste der Sicherungen ansehen.

2. Starten Sie die Wiederherstellung aus der Sicherung vor dem Upgrade. Dadurch wird ein neuer Cluster mit der vorherigen PostgreSQL-Version erstellt. Weitere Informationen finden Sie unter Cluster aus einer gespeicherten Sicherung wiederherstellen.

3. Verbinden Sie Ihre Anwendung. Aktualisieren Sie Ihre Anwendung mit Details zum wiederhergestellten Cluster und den zugehörigen Lesereplikaten. Sie können die Verarbeitung des Traffics im wiederhergestellten Cluster fortsetzen.

Sie können auch eine Wiederherstellung zu einem bestimmten Zeitpunkt vor dem Upgrade durchführen. Weitere Informationen finden Sie unter Wiederherstellung zu einem bestimmten Zeitpunkt verwenden.

Beschränkungen

Die folgenden Einschränkungen wirken sich auf In-Place-Hauptversionsupgrades von AlloyDB aus:

• Ein direktes Upgrade einer Hauptversion ist bei einem sekundären Cluster nicht möglich.
• Das Upgrade von Instanzen mit mehr als 1.000 Datenbanken von einer Version auf eine andere kann lange dauern.
• AlloyDB unterstützt keine Upgrades von Clustern, die pg_largeobject_metadata verwenden. Wenn select count(*) from pg_largeobject_metadata; nicht null ist, schlägt das Upgrade fehl.
• Das In-Place-Upgrade der Hauptversion kann abgeschlossen sein, bevor die Sicherung vor dem Upgrade oder die Sicherungen nach dem Upgrade abgeschlossen sind. Das ist insbesondere bei einer großen Datenbank mit weniger Schemaobjekten der Fall.
• Es kann zu einer kurzen Verzögerung zwischen dem Zeitpunkt, zu dem Schreibvorgänge in der aktualisierten Instanz wieder aufgenommen werden, und dem Zeitpunkt, zu dem die Sicherung nach dem Upgrade erstellt wird, kommen. Das bedeutet, dass die Inhalte der Sicherung nach dem Upgrade möglicherweise nicht mit den Inhalten der Datenbank vor dem Upgrade der Hauptversion übereinstimmen.
• Sicherungen vor dem Upgrade werden möglicherweise weiterhin erstellt, wenn ein direktes Upgrade der Hauptversion fehlschlägt.
• Da automatische Upgrade-Sicherungen kontinuierlich erfolgen, können Sie sie erst löschen, wenn sie die maximale Aufbewahrungsdauer für kontinuierliche Sicherungen und die Wiederherstellung erreicht haben. Wenn die maximale Aufbewahrungsdauer erreicht ist, werden die Sicherungen bereinigt. Alternativ können Sie die gcloud CLI verwenden, um die Sicherungen manuell zu löschen. Weitere Informationen finden Sie unter Einschränkungen beim Löschen von Sicherungen.

Nächste Schritte

• Weitere Informationen zu direkten Hauptversions-Upgrades von Datenbanken
• Fehlerbehebung bei einem direkten Upgrade einer Hauptversion
• Informationen zu Fehlern bei direkten Hauptversions-Upgrades von Datenbanken