Direkte Datenbankaktualisierung durchführen

Auf dieser Seite wird beschrieben, wie Sie die Hauptversion der Datenbank aktualisieren, indem Sie Ihre Cloud SQL-Instanz direkt aktualisieren, anstatt Daten zu migrieren.

Einführung

Anbieter von Datenbanksoftware veröffentlichen regelmäßig neue Hauptversionen, die neue Features, Leistungsverbesserungen und Sicherheitsverbesserungen enthalten. Cloud SQL übernimmt neue Versionen nach der Veröffentlichung. Sobald Cloud SQL Unterstützung für eine neue Hauptversion bietet, können Sie ein Upgrade Ihrer Instanzen durchführen, um die Datenbank auf dem neuesten Stand zu halten.

Sie können die Datenbankversion einer Instanz direkt aktualisieren oder Daten migrieren. Direkte Upgrades sind eine einfache Möglichkeit, ein Upgrade der Hauptversion einer Instanz durchzuführen. Sie müssen keine Daten migrieren oder Anwendungsverbindungsstrings ändern. Bei direkten Upgrades können Sie den Namen, die IP-Adresse und andere Einstellungen Ihrer aktuellen Instanz nach dem Upgrade beibehalten. Für direkte Upgrades ist es nicht erforderlich, Datendateien zu verschieben, und sie können schneller ausgeführt werden. In einigen Fällen ist die Ausfallzeit kürzer als bei der Migration Ihrer Daten.

Beim Cloud SQL-Vorgang für das direkte Upgrade von PostgreSQL wird das Dienstprogramm pg_upgrade verwendet.

Upgrade einer Hauptversion planen

  1. Wählen Sie eine Ziel-Hauptversion aus.

    Liste der von Cloud SQL unterstützten Versionen.

  2. Berücksichtigen Sie die in den einzelnen Datenbankversionen verfügbaren Versions- und Adressinkompatibilitäten.

    Neue Hauptversionen führen inkompatible Änderungen ein, sodass Sie möglicherweise den Anwendungscode, das Schema oder die Datenbankeinstellungen ändern müssen. Bevor Sie ein Upgrade für Ihre Datenbankinstanz durchführen können, lesen Sie die Versionshinweise Ihrer Zielhauptversion, um zu ermitteln, welche Inkompatibilitäten berücksichtigt werden müssen.

  3. Testen Sie das Upgrade im Probelauf.

    Führen Sie einen Probelauf des End-to-End-Upgradeprozesses in einer Testumgebung durch, bevor Sie die Produktionsdatenbank aktualisieren. Sie können Ihre Instanz klonen, um eine identische Kopie der Daten zu erstellen, bei denen Sie den Upgradeprozess testen können.

    Ü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 der aktualisierten Datenbank wie erwartet verhält.

  4. Legen Sie einen Zeitpunkt für das Upgrade fest.

    Für ein Upgrade darf die Instanz für einen bestimmten Zeitraum nicht verfügbar sein. Planen Sie das Upgrade in einem Zeitraum niedriger Datenbankaktivität.

Upgrade auf eine Hauptversion vorbereiten

Führen Sie vor dem Upgrade die folgenden Schritte au:

  1. Prüfen Sie den Wert LC_COLLATE für die Datenbanken template und postgres. Der Zeichensatz für jede Datenbank muss en_US.UTF8 sein.

    Wenn der Wert LC_COLLATE für die Datenbanken template und postgres nicht en_US.UTF8 ist, schlägt das Hauptversion-Upgrade fehl. Um dieses Problem zu beheben, ändern Sie den Wert LC_COLLATE vor dem Upgrade in en_US.UTF8, wenn eine der Datenbanken einen anderen Zeichensatz als en_US.UTF8 hat.

    So ändern Sie die Codierung einer Datenbank:

    1. Erstellen Sie einen Dump Ihrer Datenbank.
    2. Löschen Sie Ihre Datenbank.
    3. Erstellen Sie eine neue Datenbank mit einer anderen Codierung (in diesem Beispiel en_US.UTF8).
    4. Laden Sie die Daten neu.

  2. Verwalten Sie Ihre Lesereplikate.

    Cloud SQL for PostgreSQL unterstützt keine versionsübergreifende Replikation. Das bedeutet, dass Sie die primäre Instanz nicht aktualisieren können, während die Instanz auf die Lesereplikate repliziert. Deaktivieren Sie vor dem Upgrade entweder die Replikation für jedes Lesereplikat oder löschen Sie die Lesereplikate.

  3. Wenn Cloud SQL die logische Replikationsquelle ist, deaktivieren Sie die Replikation der Erweiterung pglogical so: Sie können sie nach dem Upgrade wieder aktivieren. Wenn Cloud SQL das logische Replikationsziel ist, sind diese Schritte nicht erforderlich.
    1. Deaktivieren Sie das Abo und trennen Sie das Replikat vom Anbieter. Führen Sie dazu den folgenden Befehl aus: 
      SELECT * FROM pglogical.alter_subscription_disable(subscription_name name, immediate bool);

      Ersetzen Sie name durch den Namen des vorhandenen Abos.

      Setzen Sie den Wert des Parameters immediate auf true, wenn das Abo sofort deaktiviert werden muss. 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)
    2. Löschen Sie den Replikations-Slot. Stellen Sie dazu eine Verbindung zum Publisher oder zur primären Cloud SQL-Instanz her und führen Sie dann den folgenden Befehl aus: 
      SELECT pg_drop_replication_slot(slot_name) FROM pg_replication_slots
  WHERE slot_name IN (SELECT slot_name FROM pg_replication_slots);

      Beispiel: 

      postgres=> SELECT pg_drop_replication_slot(slot_name) FROM pg_replication_slots
postgres->    WHERE slot_name IN (SELECT slot_name FROM pg_replication_slots);
-[ RECORD 1 ]------------+-
pg_drop_replication_slot |

postgres=>

  4. Verwalten Sie Ihre verbleibenden PostgreSQL-Erweiterungen.

    Die meisten Erweiterungen funktionieren mit der aktualisierten Hauptversion der Datenbank. Löschen Sie alle Erweiterungen, die in Ihrer Zielversion nicht mehr unterstützt werden. Löschen Sie beispielsweise die Erweiterung chkpass, wenn Sie ein Upgrade auf PostgreSQL 11 oder höher ausführen.

    Sie können PostGIS und die zugehörigen Erweiterungen manuell auf die neueste unterstützte Version aktualisieren. Wenn Ihre PostGIS-Version älter als 3.1 ist, verwenden Sie den folgenden Befehl, um die PostGIS-Erweiterung zu aktualisieren: 

        ALTER EXTENSION postgis UPDATE TO '3.1.7';
    Gelegentlich kann ein Upgrade von PostGIS Versionen 2.x dazu führen, dass Datenbankobjekte Datenbankobjekte übrig bleiben, die nicht mit der PostGIS-Erweiterung verknüpft sind. Dies kann den Upgradevorgang blockieren. Informationen zum Beheben dieses Problems finden Sie unter Fehlerhafte Postgis-Rasterinstallation beheben.

    Weitere Informationen zum Upgraden Ihrer PostGIS-Erweiterungen finden Sie unter PostGIS upgraden. Probleme im Zusammenhang mit dem Upgrade von PostGIS finden Sie unter Version Ihrer PostgreSQL-Instanz prüfen.
  5. Verwalten Sie Ihre benutzerdefinierten Datenbank-Flags. Prüfen Sie die Namen aller benutzerdefinierten Datenbank-Flags, die Sie für Ihre PostgreSQL-Instanz konfiguriert haben. Informationen zu Problemen im Zusammenhang mit diesen Flags finden Sie unter Benutzerdefinierte Flags für Ihre PostgreSQL-Instanz prüfen.
  6. Wenn Sie ein Upgrade von einer Hauptversion auf eine andere ausführen, sollten Sie versuchen, eine Verbindung zu jeder Datenbank herzustellen, um festzustellen, ob Kompatibilitätsprobleme auftreten. Sorgen Sie dafür, dass Ihre Datenbanken miteinander verbunden werden können. Prüfen Sie das Feld datallowconn für jede Datenbank, um sicherzustellen, dass eine Verbindung zulässig ist. Der Wert t bedeutet, dass dies zulässig ist. Der Wert f gibt an, dass keine Verbindung hergestellt werden kann.
  7. Wenn Sie die Installation von Datadog verwenden, um Ihre Cloud SQL-Instanz auf PostgreSQL 10 oder höher zu aktualisieren, löschen Sie vor dem Upgrade die Funktion pg_stat_activity().

Bekannte Einschränkungen

Die folgenden Einschränkungen wirken sich auf In-Place-Hauptversionsupgrades von Cloud SQL for PostgreSQL aus:

  • Das Upgrade von Instanzen mit mehr als 1.000 Datenbanken von einer Version auf eine andere kann lange dauern.
  • Mit der Anweisung select * from pg_largeobject_metadata; können Sie die Anzahl der großen Objekte in jeder PostgreSQL-Datenbank Ihrer Cloud SQL-Instanz abfragen. Wenn das Ergebnis aus allen Ihren Datenbanken mehr als 10 Millionen große Objekte beträgt, schlägt das Upgrade fehl. Cloud SQL führt ein Rollback zur vorherigen Version Ihrer Datenbank durch.

Direkte Datenbankaktualisierung durchführen

Wenn Sie einen Upgradevorgang starten, prüft Cloud SQL zuerst die Konfiguration Ihrer Instanz dahingehend, ob sie für ein Upgrade kompatibel ist. Nach der Prüfung der Konfiguration deaktiviert Cloud SQL Ihre Instanz, erstellt eine Sicherung vor dem Upgrade, führt das Upgrade durch, aktiviert Ihre Instanz und erstellt eine Sicherung nach dem Upgrade.

Console

  1. Wechseln Sie in der Google Cloud Console zur Seite Cloud SQL-Instanzen.

    Cloud SQL-Instanzen aufrufen

  2. Klicken Sie auf den Instanznamen, um die Übersichtsseite einer Instanz zu öffnen.
  3. Klicken Sie auf Bearbeiten.
  4. Klicken Sie im Abschnitt Instanzinformationen auf die Schaltfläche Upgrade und bestätigen Sie, dass Sie die Seite "Upgrade" aufrufen möchten.
  5. Klicken Sie auf der Seite Datenbankversion auswählen auf die Liste Datenbankversion für Upgrade und wählen Sie eine der verfügbaren Hauptversionen der Datenbank aus.
  6. Klicken Sie auf Weiter.
  7. Geben Sie im Feld Instanz-ID den Namen der Instanz ein und klicken Sie dann auf die Schaltfläche Upgrade starten.
Der Vorgang kann mehrere Minuten dauern.

Prüfen Sie, ob die Hauptversion der aktualisierten Datenbank unter dem Instanznamen auf der Seite Übersicht der Instanz angezeigt wird.

gcloud

  1. Starten Sie das Upgrade.

    Führen Sie den Befehl gcloud sql instances patch mit dem Flag --database-version aus.

    Ersetzen Sie vor dem Ausführen des Befehls Folgendes:

    • INSTANCE_NAME: Name der Instanz
    • DATABASE_VERSION: Der Enum für die Hauptversion der Datenbank, die größer als die aktuelle Version sein muss. Siehe die verfügbaren Datenbankversions-Enums.
    gcloud sql instances patch INSTANCE_NAME \
--database-version=DATABASE_VERSION

    Upgrades von Hauptversionen dauern einige Minuten. Möglicherweise wird eine Meldung angezeigt, die angibt, dass der Vorgang länger als erwartet dauert. Sie können diese Nachricht entweder ignorieren oder den Befehl gcloud sql operations wait ausführen, um sie zu verwerfen.

  2. Rufen Sie den Namen des Upgradevorgangs ab.

    Führen Sie den Befehl gcloud sql operations list mit dem Flag --instance aus.

    Bevor Sie den Befehl ausführen, ersetzen Sie die Variable INSTANCE_NAME durch den Namen der Instanz. 

    gcloud sql operations list --instance=INSTANCE_NAME

  3. Überwachen Sie den Status des Upgrades.

    Führen Sie folgenden Befehl gcloud sql operations describe aus.

    Bevor Sie den Befehl ausführen, ersetzen Sie die Variable OPERATION durch den Namen des Upgradevorgangs, der im vorherigen Schritt abgerufen wurde. 

    gcloud sql operations describe OPERATION

REST Version 1

  1. Starten Sie das direkte Upgrade.

    Verwenden Sie eine PATCH-Anfrage mit der Methode instances:patch.

    Ersetzen Sie diese Variablen, bevor Sie die Anfragedaten verwenden:

    • project_id: ID des Projekts
    • instance_name: Name der Instanz

    HTTP-Methode und URL:

    POST https://sqladmin.googleapis.com/v1/projects/project-id/instances/instance_name

    JSON-Text anfordern:

    {
  "databaseVersion": enum DATABASE_VERSION
}

    Ersetzen Sie DATABASE_VERSION durch den Enum der Hauptversion der Datenbank. Dieser muss größer als die aktuelle Version sein. Siehe die verfügbaren Datenbankversions-Enums.

    Senden Sie Ihre Anfrage mit curl oder PowerShell. Siehe Instanzen bearbeiten.

  2. Rufen Sie den Namen des Upgradevorgangs ab.

    Verwenden Sie eine GET-Anfrage mit der Methode operations.list, nachdem Sie project_id durch die ID des Projekts ersetzt haben.

    HTTP-Methode und URL:

    GET https://sqladmin.googleapis.com/v1/projects/project-id/operations

  3. Überwachen Sie den Status des Upgrades.

    Verwenden Sie eine GET-Anfrage mit der Methode operations.get, nachdem Sie die folgenden Variablen ersetzt haben:

    • project_id: ID des Projekts
    • operation_name: Der Name des Upgradevorgangs, der im vorherigen Schritt abgerufen wurde.

    HTTP-Methode und URL:

    GET https://sqladmin.googleapis.com/v1/projects/project-id/operation/operation_name

Terraform

Verwenden Sie zum Aktualisieren der Version der Datenbank eine Terraform-Ressource und den Terraform-Anbieter für Google Cloud, Version 4.34.0 oder höher.

resource "google_sql_database_instance" "instance" {
  name             = "postgres-instance"
  region           = "us-central1"
  database_version = "POSTGRES_14"
  settings {
    tier = "db-custom-2-7680"
  }
  # set `deletion_protection` to true, will ensure that one cannot accidentally delete this instance by
  # use of Terraform whereas `deletion_protection_enabled` flag protects this instance at the GCP level.
  deletion_protection = false
}

Änderungen anwenden

Führen Sie die Schritte in den folgenden Abschnitten aus, um Ihre Terraform-Konfiguration auf ein Google Cloud-Projekt anzuwenden.

Cloud Shell vorbereiten

  1. Rufen Sie Cloud Shell auf.

  2. Legen Sie das Google Cloud-Standardprojekt fest, auf das Sie Ihre Terraform-Konfigurationen anwenden möchten.

    Sie müssen diesen Befehl nur einmal pro Projekt und in jedem beliebigen Verzeichnis ausführen.

    export GOOGLE_CLOUD_PROJECT=PROJECT_ID

    Umgebungsvariablen werden überschrieben, wenn Sie in der Terraform-Konfigurationsdatei explizite Werte festlegen.

Verzeichnis vorbereiten

Jede Terraform-Konfigurationsdatei muss ein eigenes Verzeichnis haben (auch als Stammmodul bezeichnet).

  1. Erstellen Sie in Cloud Shell ein Verzeichnis und eine neue Datei in diesem Verzeichnis. Der Dateiname muss die Erweiterung .tf haben, z. B. main.tf. In dieser Anleitung wird die Datei als main.tf bezeichnet. 
    mkdir DIRECTORY && cd DIRECTORY && touch main.tf

  2. Wenn Sie einer Anleitung folgen, können Sie den Beispielcode in jedem Abschnitt oder Schritt kopieren.

    Kopieren Sie den Beispielcode in das neu erstellte main.tf.

    Kopieren Sie optional den Code aus GitHub. Dies wird empfohlen, wenn das Terraform-Snippet Teil einer End-to-End-Lösung ist.

  3. Prüfen und ändern Sie die Beispielparameter, die auf Ihre Umgebung angewendet werden sollen.
  4. Speichern Sie die Änderungen.
  5. Initialisieren Sie Terraform. Dies ist nur einmal für jedes Verzeichnis erforderlich. 
    terraform init

    Fügen Sie optional die Option -upgrade ein, um die neueste Google-Anbieterversion zu verwenden: 

    terraform init -upgrade

Änderungen anwenden

  1. Prüfen Sie die Konfiguration und prüfen Sie, ob die Ressourcen, die Terraform erstellen oder aktualisieren wird, Ihren Erwartungen entsprechen: 
    terraform plan

    Korrigieren Sie die Konfiguration nach Bedarf.

  2. Wenden Sie die Terraform-Konfiguration an. Führen Sie dazu den folgenden Befehl aus und geben Sie yes an der Eingabeaufforderung ein: 
    terraform apply

    Warten Sie, bis Terraform die Meldung „Apply complete“ anzeigt.

  3. Öffnen Sie Ihr Google Cloud-Projekt, um die Ergebnisse aufzurufen. Rufen Sie in der Google Cloud Console Ihre Ressourcen in der Benutzeroberfläche auf, um sicherzustellen, dass Terraform sie erstellt oder aktualisiert hat.

Änderungen löschen

So löschen Sie das Projekt:

  1. Um den Löschschutz zu deaktivieren, setzen Sie in der Terraform-Konfigurationsdatei das Argument deletion_protection auf false. 
    deletion_protection =  "false"
  2. Wenden Sie die aktualisierte Terraform-Konfiguration an. Führen Sie dazu den folgenden Befehl aus und geben Sie yes an der Eingabeaufforderung ein: 
    terraform apply

  1. Entfernen Sie Ressourcen, die zuvor mit Ihrer Terraform-Konfiguration angewendet wurden, indem Sie den folgenden Befehl ausführen und yes an der Eingabeaufforderung eingeben:

    terraform destroy

Wenn Sie eine direkte Upgradeanfrage stellen, führt Cloud SQL zuerst eine Prüfung vor dem Upgrade durch. Wenn Cloud SQL feststellt, dass die Instanz nicht für ein Upgrade bereit ist, schlägt die Upgradeanfrage mit einer Meldung dazu fehl, wie Sie das Problem beheben können. Weitere Informationen finden Sie unter Fehlerbehebung bei einem Hauptversionsupgrade.

Automatische Upgradesicherungen

Wenn Sie ein Upgrade der Hauptversion durchführen, erstellt Cloud SQL automatisch zwei On-Demand-Sicherungen, die als Upgradesicherungen bezeichnet werden:

  • Die erste Upgradesicherung ist die Sicherung vor dem Upgrade, die unmittelbar vor Beginn des Upgrades durchgeführt wird. Mit dieser Sicherung können Sie Ihre Datenbankinstanz auf den Zustand der vorherigen Version zurücksetzen.
  • Die zweite Upgrade-Sicherung ist die Sicherung nach dem Upgrade, die sofort erfolgt, nachdem neue Schreibvorgänge auf die aktualisierte Datenbankinstanz zugelassen wurden.

Wenn Sie die Liste Ihrer Sicherungen aufrufen, werden die Upgradesicherungen vom Typ On-demand aufgelistet. Upgrade-Sicherungen sind mit Labels versehen, damit Sie sie leicht identifizieren können. Wenn Sie beispielsweise ein Upgrade von PostgreSQL 9.6 auf PostgreSQL 13 ausführen, heißt die Sicherung vor dem Upgrade Pre-upgrade backup, POSTGRES_9_6 to POSTGRES_13. und Ihre Sicherung nach dem Upgrade Post-upgrade backup, POSTGRES_13 from POSTGRES_9_6..

Wie bei anderen On-Demand-Sicherungen bleiben Upgradesicherungen erhalten, bis Sie sie löschen oder die Instanz löschen. Wenn Sie PITR aktiviert haben, können Sie Ihre Upgradesicherungen nicht löschen, solange diese sich in Ihrem Zeitfenster für die Aufbewahrung befinden. Wenn Sie Ihre Upgradesicherungen löschen möchten, müssen Sie PITR deaktivieren oder warten, bis sich die Upgradesicherungen nicht mehr im Aufbewahrungsfenster befinden.

Upgrade der Hauptversion abschließen

Führen Sie nach der Aktualisierung der primären Instanz die folgenden Schritte aus, um die Aktualisierung abzuschließen:

  1. Aktivieren Sie die Replikation von pglogical, wenn Ihre Instanz sie vor dem Upgrade verwendet hat. Dadurch 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 (Replikat) neu, indem Sie der primären Cloud SQL-Instanz die folgenden Verbindungsdetails mitteilen: 
      SELECT pglogical.create_subscription(
    subscription_name := 'test_sub',
    provider_dsn := 'host=primary-ip port=5432 dbname=postgres user=replication_user password=replicapassword'
);

      Beispiel: 

      postgres=> SELECT pglogical.create_subscription(
postgres(>     subscription_name := 'test_sub',
postgres(>     provider_dsn := 'host=10.58.64.90 port=5432 dbname=postgres user=postgres password=postgres'
postgres(> );
-[ RECORD 1 ]-------+-----------
create_subscription | 2769129391
    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 Lesereplikate.

    Wenn Sie die Replikation zum Lesen von Replikaten beendet haben, aktualisieren Sie sie nacheinander. Sie können jede der Methoden verwenden, die zum Aktualisieren der primären Instanz verwendet werden. Beim Upgrade eines Replikats wird dieses von Cloud SQL unter Beibehaltung der IP-Adressen neu erstellt. Das Replikat wird mit den neuesten Daten der primären Instanz aktualisiert und neu gestartet.

    Wenn Sie Ihre Lesereplikate vor dem Upgrade der primären Instanz gelöscht haben, können Sie neue Lesereplikate erstellen, die automatisch auf der aktualisierten Datenbankversion bereitgestellt werden.

  3. Aktualisieren Sie die Datenbankstatistiken.

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

  4. Führen Sie Akzeptanztests durch.

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

Fehlerbehebung bei einem Upgrade einer Hauptversion

Cloud SQL gibt eine Fehlermeldung zurück, wenn Sie einen ungültigen Upgrade-Befehl ausführen, z. B. wenn Ihre Instanz ungültige Datenbank-Flags für die neue Version enthält.

Wenn Ihre Upgradeanfrage fehlschlägt, überprüfen Sie die Syntax der Upgradeanfrage. Wenn die Anfrage eine gültige Struktur hat, prüfen Sie die folgenden Vorschläge.

Fehler bei der Prüfung vor dem Upgrade ansehen

Fehler bei der Prüfung vor dem Upgrade sind Probleme oder Fehler, die Cloud SQL während der Überprüfung oder Validierung vor dem Upgrade erkennt. Diese Fehler treten vor dem eigentlichen Upgradeprozess auf und sollen potenzielle Probleme oder Inkompatibilitäten identifizieren, die sich auf den Erfolg des Upgrades auswirken können.

Fehler bei der Prüfung vor dem Upgrade werden für die folgenden Kategorien angezeigt:

  • Inkompatible Erweiterungen: Ermitteln Sie PostgreSQL-Erweiterungen, die nicht mit der Zielversion der Instanz kompatibel sind.
  • Nicht unterstützte Abhängigkeiten: Ermitteln Sie Abhängigkeiten, die nicht mehr unterstützt werden oder aktualisiert werden müssen.
  • Datenformatinkompatibilitäten: Prüfen Sie Dateninkonsistenzen, die sich aus verschiedenen Faktoren ergeben, einschließlich Unterschiede bei versionsspezifischen Datenstrukturen, Änderungen bei der Codierung und Sortierung, Änderungen an Datentypen und Anpassungen am Systemkatalog.

In der folgenden Tabelle sind die Fehler bei der Prüfung vor dem Upgrade und deren Fehlermeldungen aufgeführt.

Fehler bei der Prüfung vor dem Upgrade Fehlermeldung
Cloud SQL erkennt einen unbekannten Datentyp. Please remove the following usages of 'Unknown' data types before attempting an upgrade: (database: db_name, relation: rel_name, attribute: attr_name)
Beim Upgrade auf PostgreSQL 12 oder höher erkennt Cloud SQL den Datentyp 'sql_identifier'. Please remove the following usages of 'sql_identifier' data types before attempting an upgrade: (database: db_name, relation: rel_name, attribute: attr_name)
Cloud SQL erkennt den Datentyp reg*. Please remove the following usages of 'reg*' data types before attempting an upgrade: (database: db_name, relation: rel_name, attribute: attr_name)
Cloud SQL erkennt, dass der Wert
LC_COLLATE für die Datenbank postgres ein anderer Zeichensatz als en_US.UTF8 ist.		 Please change the 'LC_COLLATE' value of the postgres database to 'en_US.UTF8' before attempting an upgrade
Cloud SQL erkennt Tabellen mit Objektkennungen (OIDs). Please remove the following usages of tables with OIDs before attempting an upgrade: (database: db_name, relation: rel_name)
Cloud SQL erkennt zusammengesetzte Datentypen. Please remove the following usages of 'composite' data types before attempting an upgrade: (database: db_name, relation: rel_name, attribute: attr_name)
Cloud SQL erkennt benutzerdefinierte Postfix-Operatoren. Please remove the following usages of 'composite' data types before attempting an upgrade: (database: db_name, operation id: op_id, operation namespace: op_namespace, operation name: op_name, type namespace: type_namespace, type name: type_name)
Cloud SQL erkennt inkompatible polymorphe Funktionen. Please remove the following usages of 'incompatible polymorphic' functions before attempting an upgrade: (database: db_name, object kind: obj_kind, object name: obj_name)
Cloud SQL erkennt benutzerdefinierte Codierungskonvertierungen. Please remove the following usages of user-defined encoding conversions before attempting an upgrade: (database: db_name, namespace name: namespace_name, encoding conversions name: encod_name)

Upgradelogs ansehen

Wenn bei einer gültigen Upgradeanfrage Probleme auftreten, veröffentlicht Cloud SQL Fehlerlogs in projects/PROJECT_ID/logs/cloudsql.googleapis.com%2Fpostgres-upgrade.log. Jeder Logeintrag enthält ein Label mit der Instanzkennung, damit Sie die Instanz mit dem Upgradefehler identifizieren können. Suchen Sie nach solchen Upgradefehlern und beheben Sie sie.

So rufen Sie Fehlerlogs auf:

  1. Wechseln Sie in der Google Cloud Console zur Seite Cloud SQL-Instanzen.

    Cloud SQL-Instanzen aufrufen

  2. Klicken Sie auf den Instanznamen, um die Übersichtsseite einer Instanz zu öffnen.

  3. Klicken Sie auf der Seite Übersicht der Instanz im Bereich Vorgänge und Logs auf den Link PostgreSQL-Fehlerlogs aufrufen.

    Die Seite Log-Explorer wird geöffnet.

  4. So rufen Sie Logs auf:

    • Wählen Sie den Lognamen im Logfilter Logname aus, um alle Fehlerlogs in einem Projekt aufzulisten.

    Weitere Informationen zu Abfragefiltern finden Sie unter Erweiterte Abfragen.

    • Um die Upgradefehlerlogs für eine einzelne Instanz zu filtern, geben Sie die folgende Abfrage in das Feld In allen Feldern suchen ein, nachdem Sie DATABASE_ID

    durch die Projekt-ID ersetzt haben, gefolgt vom Instanznamen im folgenden Format: project_id:instance_name.

    resource.type="cloudsql_database"
resource.labels.database_id="DATABASE_ID"
logName : "projects/PROJECT_ID/logs/cloudsql.googleapis.com%2Fpostgres-upgrade.log"

    Verwenden Sie beispielsweise den folgenden Abfragefilter, um die Upgradefehlerlogs nach einer Instanz namens shopping-db zu filtern, die im Projekt buylots ausgeführt wird:

     resource.type="cloudsql_database"
 resource.labels.database_id="buylots:shopping-db"
 logName : "projects/buylots/logs/cloudsql.googleapis.com%2Fpostgres-upgrade.log"

Logeinträge mit dem Präfix pg_upgrade_dump geben an, dass ein Upgradefehler aufgetreten ist. Beispiel:

pg_upgrade_dump: error: query failed: ERROR: out of shared memory
HINT: You might need to increase max_locks_per_transaction.

Darüber hinaus werden in Logeinträgen, die mit einem sekundären .txt-Dateinamen versehen sind, eventuell weitere Fehler aufgeführt, die Sie beheben sollten, bevor Sie das Upgrade wiederholen.

Alle Dateinamen finden Sie in der Datei postgres-upgrade.log. Informationen zu einem Dateinamen finden Sie im Feld labels.FILE_NAME.

Folgende Dateinamen enthalten möglicherweise Fehler, die behoben werden sollten:

  • tables_with_oids.txt: Diese Datei enthält Tabellen, die mit Objekt-IDs (OIDs) aufgeführt sind. Löschen Sie die Tabellen oder ändern Sie sie so, dass sie keine OIDs verwenden.
  • tables_using_composite.txt:Diese Datei enthält Tabellen, die mit vom System definierten zusammengesetzten Typen aufgelistet werden. Löschen Sie entweder die Tabellen oder ändern Sie sie so, dass sie diese zusammengesetzten Typen nicht verwenden.
  • tables_using_unknown.txt: Diese Datei enthält Tabellen, die mithilfe dem Datentyp UNKNOWN aufgelistet werden. Löschen Sie die Tabellen oder ändern Sie sie so, dass sie diesen Datentyp nicht verwenden.
  • tables_using_sql_identifier.txt: Diese Datei enthält Tabellen, die mithilfe dem Datentyp SQL_IDENTIFIER aufgelistet werden. Löschen Sie die Tabellen oder ändern Sie sie so, dass sie diesen Datentyp nicht verwenden.
  • tables_using_reg.txt: Diese Datei enthält Tabellen, die mithilfe dem Datentyp REG* aufgelistet werden (z. B. REGCOLLATION oder REGNAMESPACE). Löschen Sie die Tabellen oder ändern Sie sie so, dass sie diesen Datentyp nicht verwenden.
  • postfix_ops.txt:Diese Datei enthält Tabellen, die mit Postfix-Operatoren (rechts-unär) aufgelistet sind. Löschen Sie die Tabellen oder ändern Sie sie so, dass sie diese Operatoren nicht verwenden.

Arbeitsspeicher prüfen

Wenn die Instanz nicht genügend freigegebenen Arbeitsspeicher hat, wird möglicherweise diese Fehlermeldung angezeigt: ERROR: out of shared memory. Dieser Fehler tritt wahrscheinlich auf, wenn Sie mehr als 10.000 Tabellen haben.

Bevor Sie ein Upgrade ausführen, setzen Sie den Wert des Flags max_locks_per_transaction auf etwa die doppelte Anzahl von Tabellen in der Instanz. Die Instanz wird neu gestartet, wenn Sie den Wert dieses Flags ändern.

Verbindungskapazität prüfen

Wenn Ihre Instanz keine ausreichende Verbindungskapazität hat, wird möglicherweise diese Fehlermeldung angezeigt: ERROR: Insufficient connections.

Cloud SQL empfiehlt, den Flag-Wert max_connections um die Anzahl der Datenbanken in Ihrer Instanz zu erhöhen. Die Instanz wird neu gestartet, wenn Sie den Wert dieses Flags ändern.

Version der PostgreSQL-Instanz prüfen

Wenn Sie Version 9.6, 10 oder 11 einer Cloud SQL for PostgreSQL-Instanz verwenden und die PostGIS-Erweiterung für die Instanz aktiviert haben, kann das Upgrade von PostGIS aufgrund eines Berechtigungsproblems fehlschlagen. Verwenden Sie zur Behebung dieses Problems die Self-Service-Wartung, um das neueste SSM-Image (Systems Manager) bereitzustellen. Dadurch erhalten Sie die Berechtigung, ein Upgrade für PostGIS durchzuführen.

Benutzerdefinierte Flags für Ihre PostgreSQL-Instanz prüfen

Wenn Sie ein Upgrade auf eine PostgreSQL-Instanz der Version 14 oder höher ausführen, prüfen Sie die Namen der benutzerdefinierten Datenbank-Flags, die Sie für die Instanz konfiguriert haben. Dies liegt daran, dass PostgreSQL zusätzliche Einschränkungen für zulässige Namen für benutzerdefinierte Parameter platziert hat.

Das erste Zeichen eines benutzerdefinierten Datenbank-Flags muss alphabetisch (A–Z oder a–z) sein. Alle nachfolgenden Zeichen können alphanumerische Zeichen, Sonderzeichen (_) oder das Sonderzeichen Dollar ($) sein.

Erweiterungen entfernen

Wenn Sie Ihre Cloud SQL-Instanz von Version 10 auf Version 14 aktualisieren, wird möglicherweise diese Fehlermeldung angezeigt: pg_restore: error: could not execute query: ERROR: role "16447" does not exist.

Führen Sie die folgenden Schritte aus, um das Problem zu beheben:

  1. Entfernen Sie die Erweiterungen pg_stat_statements und pgstattuple.
  2. Führen Sie das Upgrade aus.
  3. Installieren Sie die Erweiterungen neu.

Wiederherstellung der vorherigen Hauptversion

Wenn das aktualisierte Datenbanksystem nicht wie erwartet funktioniert, müssen Sie die Instanz möglicherweise in der vorherigen Version wiederherstellen. Dazu stellen Sie die Sicherung vor dem Upgrade in einer Cloud SQL-Wiederherstellungsinstanz wieder her. Dabei handelt es sich um eine neue Instanz, auf der die Version vor dem Upgrade ausgeführt wird.

Gehen Sie so vor, um die vorherige Version wiederherzustellen:

  1. Ermitteln Sie die Sicherung vor dem Upgrade.

    Siehe Automatische Upgradesicherungen.

  2. Erstellen Sie eine Wiederherstellungsinstanz.

    Erstellen Sie eine neue Cloud SQL-Instanz mithilfe der Hauptversion, die Cloud SQL beim Erstellen der Sicherung vor dem Upgrade ausgeführt hat. Legen Sie dieselben Flags und Instanzeinstellungen fest wie für die ursprüngliche Instanz.

  3. Stellen Sie die Sicherung vor dem Upgrade wieder her.

    Stellen Sie die Sicherung vor dem Upgrade auf der Wiederherstellungsinstanz wieder her. Die Ausführung dieses Befehls kann mehrere Minuten dauern.

  4. Fügen Sie die Lesereplikate hinzu.

    Wenn Sie Lesereplikate verwendet haben, fügen Sie sie einzeln hinzu.

  5. Verbinden Sie Ihre Anwendung.

    Nachdem Sie das Datenbanksystem wiederhergestellt haben, aktualisieren Sie Ihre Anwendung mit Details über die Wiederherstellungsinstanz und die zugehörigen Lesereplikate. Sie können die Verarbeitung des Traffics in der Version der Datenbank vor dem Upgrade fortsetzen.

Beschränkungen

In diesem Abschnitt werden die Einschränkungen für das direkte Upgrade der Hauptversion aufgeführt.

  • Sie können kein direktes Upgrade der Hauptversion auf einem externen Replikat durchführen.

Häufig gestellte Fragen

Bei der Aktualisierung der Hauptversion der Datenbank können die folgenden Fragen auftreten.

Ist meine Instanz während eines Upgrades nicht verfügbar?
Ja. Die Instanz ist für einen bestimmten Zeitraum nicht verfügbar, während Cloud SQL das Upgrade durchführt.
Wie lange dauert ein Upgrade?

Das Upgrade einer einzelnen Instanz dauert in der Regel weniger als 10 Minuten. Wenn Ihre Instanzkonfiguration eine kleine Menge von vCPUs oder Arbeitsspeicher verwendet, kann Ihr Upgrade mehr Zeit in Anspruch nehmen.

Wenn Ihre Instanz zu viele Datenbanken oder Tabellen hostet oder Ihre Datenbanken sehr groß sind, kann das Upgrade Stunden oder sogar eine Zeitüberschreitung verursachen, da die Upgradezeit der Anzahl der Objekte in Ihren Datenbanken entspricht. Wenn Sie mehrere Instanzen aktualisieren müssen, wird die Gesamtupgradedauer proportional erhöht.

Kann ich die einzelnen Schritte in meinem Upgrade-Prozess überwachen?
Mit Cloud SQL können Sie zwar beobachten, ob ein Upgradevorgang noch läuft, Sie können jedoch nicht die einzelnen Schritte in jedem Upgrade verfolgen.
Kann ich mein Upgrade nach dem Start abbrechen?
Nein, Sie können ein Upgrade nicht mehr abbrechen, nachdem es gestartet wurde. Wenn Ihr Upgrade fehlschlägt, stellt Cloud SQL Ihre Instanz automatisch mit der vorherigen Version wieder her.
Was geschieht mit meinen Einstellungen während eines Upgrades?

Wenn Sie ein direktes Upgrade der Hauptversion durchführen, behält Cloud SQL Ihre Datenbankeinstellungen bei, einschließlich Instanzname, IP-Adresse, explizit konfigurierte Flag-Werte und Nutzerdaten bei. Der Standardwert der Systemvariablen kann sich jedoch ändern. Der Standardwert des Flags password_encryption in PostgreSQL 13 und früheren Versionen ist beispielsweise md5. Wenn Sie ein Upgrade auf PostgreSQL 14 durchführen, ändert sich der Standardwert dieses Flags in scram-sha-256.

Weitere Informationen finden Sie unter Datenbank-Flags konfigurieren. Wenn ein bestimmtes Flag oder ein Wert in Ihrer Zielversion nicht mehr unterstützt wird, entfernt Cloud SQL das Flag während des Upgrades automatisch.

Nächste Schritte