Direktes Upgrade der Datenbankhauptversion durchführen

Wenn Sie ein Upgrade eines AlloyDB for PostgreSQL-Clusters auf eine höhere PostgreSQL-Hauptversion durchführen und dabei Ihre vorhandenen Instanznamen, IP-Adressen und Verbindungsstrings beibehalten möchten, können Sie ein In-Place-Hauptversionsupgrade planen, validieren und ausführen. Informationen zu Anwendungsfällen, Workflowphasen und automatischen Sicherungen für direkte Hauptversionsupgrades finden Sie unter Übersicht über direkte Hauptversionsupgrades von Datenbanken.

Upgrade einer Hauptdatenbankversion planen

So planen Sie ein Upgrade der Hauptversion der Datenbank:

  1. Ermitteln Sie die aktuelle 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 zu 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 Region

    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 Region

    Wenn Sie die Anfrage senden möchten, wählen Sie eine der folgenden Optionen aus:

    curl (Linux, macOSoder Cloud Shell)

    Führen Sie den 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. Wählen Sie in der folgenden Tabelle eine Hauptversion der Zieldatenbank aus. 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_17
    • POSTGRES_18
    POSTGRES_15
    • POSTGRES_16
    • POSTGRES_17
    • POSTGRES_18
    POSTGRES_16
    • POSTGRES_17
    • POSTGRES_18
    POSTGRES_17
    • POSTGRES_18

  3. Sehen Sie sich die in den einzelnen Datenbank-Hauptversionen verfügbaren Funktionen an.

  4. Identifizieren 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 auf Ihrem Produktionscluster starten, empfehlen wir Ihnen, Ihren Cluster zu klonen und das Upgrade der Hauptversion auf dem 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 auf ein Upgrade der Hauptversion vorbereiten

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

1. Regionenübergreifende Replikate löschen oder hochstufen Direkte Upgrades der Hauptversion der Datenbank unterstützen keine regionenübergreifenden Replikate. Weitere Informationen finden Sie unter Regionenübergreifende Replikation.

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

    1. Deaktivieren Sie jedes nachgelagerte Abo auf dem Abonnenten oder nachgelagerten Replikationsziel. Deaktivieren Sie die nachgelagerten Abos auf der AlloyDB-Instanz, die aktualisiert wird, nicht:

      • 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, indem Sie den folgenden Befehl ausführen:

      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 Replikationsslots.

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

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

    Möglicherweise ist Folgendes nötig:

    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 PostgreSQL-Zielversion. Weitere Informationen finden Sie unter PostGIS-Erweiterungen. In der folgenden Tabelle sind die unterstützten Mindestversionen der PostGIS-Erweiterung für jede PostgreSQL-Hauptversion aufgeführt:

      PostgreSQL-Version Unterstützte PostGIS-Mindestversion
      PG14 3.1
      PG15 3.2
      PG16 3.4
      PG17 3,5
      PG18 3,6

      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();

  3. Prüfen Sie, ob Ihre Cluster verwaiste Rollenmitgliedschaften enthalten. Bei direkten Upgrades von Hauptversionen werden Rollenmitgliedschaften nicht beibehalten, wenn der ursprüngliche Ersteller nicht mehr vorhanden ist. Wenn ein Cluster verwaiste Mitgliedschaften im pg_auth_members-Katalog enthält, gehen diese Rollenmitgliedschaften nach dem Upgrade verloren.

    Führen Sie die folgende Abfrage aus, um verwaiste Mitgliedschaften zu erkennen:

    SELECT roleid::regrole, member::regrole, grantor::regrole
FROM pg_auth_members
WHERE grantor::regrole::text ~ '^[0-9]+$';

    Wenn die Abfrage Zeilen zurückgibt, erstellen Sie die Rollenmitgliedschaften neu, bevor Sie den Cluster aktualisieren. Entziehen Sie für jede verwaiste Mitgliedschaft die Berechtigung und gewähren Sie sie sofort wieder. Dadurch wird die Mitgliedschaft mit einem aktuellen, gültigen Grantor (z. B. alloydbadmin) verknüpft.

    Führen Sie den folgenden Transaktionsblock für jede verwaiste Mitgliedschaft aus:

    BEGIN;
REVOKE ROLE_NAME FROM MEMBER_NAME;
GRANT ROLE_NAME TO MEMBER_NAME;
COMMIT;

    Ersetzen Sie ROLE_NAME und MEMBER_NAME durch die Rollen aus den Abfrageergebnissen.

  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 den Wert f hat, legen Sie ihn 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 eine Hauptversion stellen, führt AlloyDB zuerst Prüfungen vor dem Upgrade durch. Wenn AlloyDB feststellt, dass Ihr Cluster nicht für ein Upgrade der Hauptversion bereit ist, schlägt die Anfrage fehl. Weitere Informationen finden Sie unter Fehlerbehebung bei einem direkten Upgrade einer Hauptversion.

So führen Sie ein direktes Upgrade der Hauptversion der Datenbank durch:

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. Klicken Sie auf Upgrade, um das Upgrade der Hauptversion der Datenbank zu starten.

  4. Wählen Sie im Schritt Datenbankversion auswählen eine der verfügbaren Hauptversionen der Datenbank als Ziel-Hauptversion aus.

  5. Klicken Sie auf Weiter.

  6. Geben Sie im Schritt Cluster aktualisieren im Feld Cluster-ID den Namen des Clusters ein.

  7. Klicken Sie auf Upgrade starten. Sie werden zum Schritt Upgradestatus weitergeleitet, in dem Sie den Upgradestatus prüfen können. Weitere Informationen finden Sie unter Upgrade der Datenbank-Hauptversion überwachen.

gcloud

Starten Sie das direkte Upgrade der Hauptversion mit dem folgenden Befehl:

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

Hier ein Beispielbefehl:

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

REST v1beta

Starten Sie das direkte Upgrade der Hauptversion mit dem folgenden Befehl:

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

JSON-Text der Anfrage:

{
  "version": "DATABASE_VERSION"
}

Ersetzen Sie dies durch den Enum für die Hauptversion der Zieldatenbank, die höher als die aktuelle Version sein muss.

Beispiel für JSON-Anfragetext:

{
"version": "POSTGRES_16"
}
* { Terraform }





To upgrade an instance within your database cluster to a PostgreSQL version, use a [Terraform resource](https://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/alloydb_instance) and set the `database_version` to a [supported target major version](/alloydb/docs/upgrade-db-inplace-major-version#plan-upgrade).

```none
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]
}
```

To learn how to apply or remove a Terraform configuration, see [Basic Terraform commands](/docs/terraform/basic-commands).

Upgrade der Hauptversion des Clusters überwachen

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

Console

So prüfen Sie den Upgradestatus in der Google Cloud Console:

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

    Zu den Clustern

  2. Wählen Sie den Cluster aus, der aktualisiert wird. Die Seite Übersicht wird angezeigt.

  3. Öffnen Sie die Seite Übersicht.

  4. Klicken Sie auf Upgrade-Status. Die Seite Upgradestatus wird angezeigt. Hier können Sie den Status des Upgrades prüfen.

gcloud

So prüfen Sie den Upgradestatus in der gcloud CLI:

  1. Rufen Sie die ID des Upgradevorgangs mit dem folgenden Befehl ab. Ersetzen Sie vor dem Ausführen des Befehls die Variable CLUSTER_ID durch den Namen des Clusters:

    gcloud alloydb operations list --cluster=CLUSTER_ID --region=REGION_ID --filter=metadata.verb:upgrade

    Der gcloud CLI-Aufruf, der zum Auslösen eines Upgrades auf eine Hauptversion verwendet wird. alloydb beta clusters upgrade, gibt die Vorgangs-ID als synchrone Antwort zurück. Alternativ können Sie den Befehl gcloud alloydb operations list mit dem Flag --cluster verwenden.

    Hier ein Beispielbefehl:

    gcloud alloydb operations list --cluster=my-cluster --region=us-central1 --filter=metadata.verb:upgrade

  2. Überwachen Sie den Status des Upgrades mit dem Befehl gcloud alloydb operations describe:

    gcloud alloydb operations describe OPERATION_ID
--region=REGION

REST v1beta

So prüfen Sie den Upgradestatus in der REST API:

  1. Rufen Sie die Vorgangs-ID des Upgrades ab.

    Verwenden Sie die folgende GET-Anfrage mit der Methode operations.list, um alle Upgradevorgänge aufzulisten und den Vorgang zu finden, der dem Zielcluster entspricht:

    GET https://alloydb.googleapis.com/v1beta/projects/PROJECT_ID/locations/REGION/operations/filter=metadata.verb:upgrade

    Der REST API-Aufruf gibt die Vorgangs-ID als synchrone Antwort zurück.

  2. Überwachen Sie den Status des Upgrades.

    Verwenden Sie eine GET-Anfrage mit der Methode operations.get:

      GET https://alloydb.googleapis.com/v1beta/projects/PROJECT_ID/locations/REGION/operations/OPERATION_ID

    Ersetzen Sie die folgenden Werte:

    • PROJECT_ID: die Projekt-ID
    • REGION: Der Clusterstandort oder die Region
    • OPERATION_ID: die ID des Upgradevorgangs, die im vorherigen Schritt abgerufen wurde.

    Hier sehen Sie ein Beispiel für eine Antwort, wenn der Vorgang läuft:

    {
"name": "projects/PROJECT_ID/locations/REGION/operations/OPERATION_ID",
"metadata": {
"@type": "type.googleapis.com/google.cloud.alloydb.v1.OperationMetadata",
"createTime": "2024-09-16T23:17:39.727319438Z",
"target": "projects/PROJECT_ID/locations/REGION/clusters/CLUSTER_ID",
"verb": "upgrade",
"requestedCancellation": false,
"apiVersion": "v1",
"upgradeClusterStatus": {
   "state": "IN_PROGRESS",
   "cancellable": true,
   "stages": [
    {
      "stage": "ALLOYDB_PRECHECK",
      "state": "IN_PROGRESS"
    },
    {
      "stage": "PG_UPGRADE_CHECK",
      "state": "IN_PROGRESS"
    },
    {
      "stage": "PREPARE_FOR_UPGRADE",
      "state": "NOT_STARTED"
    },
    {
      "stage": "PRIMARY_INSTANCE_UPGRADE",
      "state": "NOT_STARTED"
    },
    {
      "stage": "CLEANUP",
      "state": "NOT_STARTED"
    }
   ]
 }
},
"done":false
}

    Hier ist eine Beispielantwort, wenn der Vorgang abgeschlossen ist:

    {
"operations": [
{
 "metadata": {
 "@type": "type.googleapis.com/google.cloud.alloydb.v1betaalpha.OperationMetadata",
 "createTime": "2024-09-16T21:52:17.303861317Z",
 "endTime": "2024-09-16T22:29:13.947527949Z",
 "target": "projects/PROJECT_ID/locations/REGION/clusters/CLUSTER_ID",
 "verb": "upgrade",
 "requestedCancellation": false,
 "apiVersion": "v1beta",
 "upgradeClusterStatus": {
  "state": "SUCCESS",
  "stages": [
    {
      "stage": "ALLOYDB_PRECHECK",
      "state": "SUCCESS"
    },
    {
      "stage": "PG_UPGRADE_CHECK",
      "state": "SUCCESS"
    },
    {
      "stage": "PREPARE_FOR_UPGRADE",
      "state": "SUCCESS"
    },
    {
      "stage": "PRIMARY_INSTANCE_UPGRADE",
      "state": "SUCCESS"
    },
    {
      "stage": "CLEANUP",
      "state": SUCCESS"
    }
   ]
 }
},
"response": {
     …
},
"name":  "projects/PROJECT_ID/locations/REGION/operations/OPERATION_ID",
"done": true
}
]
}

    Weitere Informationen zur response-Struktur finden Sie unter Antwort auf Upgradevorgang.

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: enthält eine kurze Zusammenfassung des Ergebnisses des Upgradevorgangs.
  • clusterUpgradeDetails: Upgradedetails für die Cluster, die aktualisiert werden. Dieses Feld ist ein Array. AlloyDB lässt nur ein einzelnes Clusterupgrade zu, daher ist nur ein Eintrag enthalten.
    • name: Voll qualifizierter Name des Clusters.
    • upgradeStatus: der Status des Clusterupgrades. Mögliche Werte sind SUCCESS, FAILED und PARTIAL_SUCCESS. PARTIAL_SUCCESS bedeutet, dass für eine oder mehrere Lesepoolinstanzen kein Upgrade durchgeführt werden kann.
    • clusterType: der Clustertyp. In AlloyDB können Sie nur einen einzelnen PRIMARY-Cluster aktualisieren. Dieser Typ muss immer PRIMARY sein.
    • databaseVersion: die aktuelle Datenbankversion des Clusters.
    • stageInfo: Informationen zu den wichtigsten Upgradephasen.
      • status: SUCCESS oder FAILED
      • logs_url: Link zu den von der Phase generierten Logs. Leer für Phasen, die keine Logs generieren.
    • 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 eine Beispielantwort für einen Upgradevorgang:

"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 Log mit dem Namen postgres_upgrade.

So rufen Sie Logs im Zusammenhang mit Upgrades auf:

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

    Zum Log-Explorer

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

  2. Wählen Sie alloydb.googleapis.com/postgres_upgrade als Lognamen aus. Dies 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

    		 Upgradephase, in der das Log generiert wurde. Mögliche Werte sind ALLOYDB_PRECHECK, PG_UPGRADE_CHECK und PG_UPGRADE.

    OPERATION_NAME

    		 Vollständiger Vorgangsname für den Upgradevorgang.

    FILE_NAME

    		 Wird nur für pg_upgrade_check- und pg_upgrade-Logs ausgefüllt und entspricht den Logdateien, die vom Dienstprogramm pg_upgrade generiert werden.

Im Folgenden finden Sie eine Beispielabfrage, die AlloyDB-Upgrade-Logs vor der Prüfung 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 Übersicht über das direkte Upgrade der Datenbank-Hauptversion.

Upgradelogs für einen Cluster ansehen

So rufen Sie die Upgrade-Logs 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 das und die Seite Log-Explorer auf:

    Zum Log-Explorer

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

  2. Fragen Sie die AlloyDB-Pre-Check-Logs für Ihren Cluster ab.

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

  3. Suchen Sie im Loglabel OPERATION_NAME nach 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. Fragen Sie alle postgres_upgrade-Logs für einen bestimmten Vorgang ab.

    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 ein laufendes Upgrade auf eine Hauptversion über die Google Cloud Console, die gcloud CLI oder die REST API abbrechen.

Vorgangs-ID ermitteln

Wenn Sie den Upgradevorgang für die 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. Siehe Beispielantwort.

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

Upgrade abbrechen

So brechen Sie ein direktes Upgrade der Hauptversion ab:

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. Klicken Sie auf Upgrade status.

  4. Klicken Sie auf Upgrade abbrechen. Wenn das Upgrade nicht abgebrochen werden kann, ist diese Schaltfläche ausgegraut.

gcloud

Verwenden Sie den Befehl gcloud alloydb operations cancel, um den Vorgang abzubrechen:

gcloud alloydb operations cancel OPERATION_ID

Ersetzen Sie die Variable OPERATION_ID durch die ID des Vorgangs.

Wenn in der Ausgabe des Befehls gcloud alloydb operations cancel für UpgradeClusterStatus der Wert cancellable als false angezeigt wird, ignoriert AlloyDB die Abbruchanfrage und fährt mit dem Upgrade fort. In diesem Fall gibt die API keinen Fehler, sondern eine leere Antwort zurück. Weitere Informationen zum Upgradestatus finden Sie unter Upgrade der Hauptversion des Clusters überwachen.

REST v1beta

Führen Sie dazu diesen Befehl aus:

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

Ersetzen Sie folgende Werte in den Anfragedaten:

  • PROJECT_ID: Projekt-ID.
  • OPERATION_ID: die ID des Import- oder Exportvorgangs.

Wenn cancellable in UpgradeClusterStatus den Wert false hat, können Sie das Upgrade nicht abbrechen.

Wenn Sie die Anfrage senden möchten, wählen Sie eine der folgenden Optionen aus:

curl (Linux, macOSoder Cloud Shell)

Führen Sie dazu diesen Befehl aus:

       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"

PowerShell (Windows)

Führen Sie dazu diesen Befehl aus:

       $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

Sie sollten eine JSON-Antwort ähnlich wie diese erhalten:

Antwort

Dieser REST API-Aufruf gibt keine Antwort zurück.

Direktes Upgrade der Hauptversion abschließen

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

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

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

  1. Wenn Sie pglogical zuvor deaktiviert haben, aktivieren Sie die pglogical-Replikation wieder. 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

    2. Erstellen Sie das pglogical-Abo auf dem Ziel oder Replikat neu, indem Sie der primären AlloyDB-Instanz die folgenden Verbindungsinformationen mitteilen:

        SELECT pglogical.create_subscription(
  subscription_name :='test_sub',<br>
  provider_dsn := 'host=primary-ip port=5432 dbname=postgres user=replication_user password=replicapassword'
  );

    3. Prüfen Sie den Status des Abos mit folgendem Befehl:

        SELECT * FROM pglogical.show_subscription_status('test_sub');

    4. Testen Sie die Replikation, indem Sie Schreibtransaktionen ausführen und prüfen, ob die Änderungen am Ziel sichtbar sind.

  2. Aktualisieren Sie die Datenbankerweiterungen in Ihren aktualisierten Datenbanken manuell.

    Bei Upgrades der Hauptversion werden zwar automatisch die neuesten Erweiterungsbinärdateien auf der zugrunde liegenden Software Ihrer Instanz installiert, der Datenbankkatalog der Erweiterung wird jedoch nicht automatisch aktualisiert. Sie sind dafür verantwortlich, Ihre Erweiterungen manuell zu aktualisieren, damit die neuesten unterstützten Versionen verwendet werden. Eine Anleitung finden Sie unter Erweiterung aktualisieren.

  3. 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.

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

  5. Prüfen Sie, ob die aktualisierte Hauptversion der 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 den Zustand vor dem Upgrade wiederherstellen. Dazu können Sie eine Sicherung vor dem Upgrade wiederherstellen, entweder die, die AlloyDB während des Upgrades automatisch erstellt, oder eine vorhandene Sicherung vor dem Upgrade, um einen neuen Cluster mit dem Zustand vor dem Upgrade zu erstellen.

So stellen Sie den Zustand vor dem Upgrade wieder her:

  1. Ermitteln Sie eine Sicherung vor dem Upgrade, aus der Sie 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. Initiieren Sie eine 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 ausführen. Weitere Informationen finden Sie unter Wiederherstellung zu einem bestimmten Zeitpunkt (PITR) 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. – Wenn Sie ein direktes Upgrade der Hauptversion durchführen, beachten Sie, dass das Upgrade von Instanzen mit mehr als 1.000 Datenbanken oder 1 Million Objekten (z. B. Tabellen und Ansichten) lange dauert und es zu einer Zeitüberschreitung kommen kann. Diese Einschränkung ist unabhängig von der tatsächlichen Datengröße. - AlloyDB unterstützt kein Upgrade von Clustern, die pg_largeobject_metadata verwenden. Wenn select count(*) from pg_largeobject_metadata; ungleich null ist, schlägt das Upgrade fehl. - AlloyDB behält keine Rollenmitgliedschaften bei, wenn der ursprüngliche Gewährer nicht mehr existiert. Wenn Ihre Datenbank diese verwaisten Mitgliedschaften enthält, müssen Sie sie vor dem Upgrade beheben. Weitere Informationen finden Sie unter Cluster vorbereiten. – Das direkte Upgrade der Hauptversion wird möglicherweise vor der Sicherung vor dem Upgrade oder vor den Sicherungen nach dem Upgrade abgeschlossen, insbesondere wenn Sie eine große Datenbank mit weniger Schemaobjekten haben. – Es kann zu einer kurzen Verzögerung zwischen dem Zeitpunkt, an dem Schreibvorgänge auf der aktualisierten Instanz wieder gestartet werden, und dem Zeitpunkt, an 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 auch dann erstellt, wenn ein direktes Upgrade einer Hauptversion fehlschlägt. – Da automatische Upgradesicherungen kontinuierlich erfolgen, können Sie sie erst löschen, wenn sie die maximale Aufbewahrungsdauer für kontinuierliche Sicherungen und Wiederherstellungen erreicht haben. Wenn die maximale Aufbewahrungsdauer erreicht ist, werden die Sicherungen automatisch gelöscht. 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