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 Dienstprogrammpg_upgrade
verwendet.
Upgrade einer Hauptversion planen
Wählen Sie eine Ziel-Hauptversion aus.
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.
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.
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:
-
Prüfen Sie den Wert
LC_COLLATE
für die Datenbankentemplate
undpostgres
. Der Zeichensatz für jede Datenbank mussen_US.UTF8
sein.Wenn der Wert
LC_COLLATE
für die Datenbankentemplate
undpostgres
nichten_US.UTF8
ist, schlägt das Hauptversion-Upgrade fehl. Um dieses Problem zu beheben, ändern Sie den WertLC_COLLATE
vor dem Upgrade inen_US.UTF8
, wenn eine der Datenbanken einen anderen Zeichensatz alsen_US.UTF8
hat.So ändern Sie die Codierung einer Datenbank:
- Erstellen Sie einen Dump Ihrer Datenbank.
- Löschen Sie Ihre Datenbank.
- Erstellen Sie eine neue Datenbank mit einer anderen Codierung (in diesem Beispiel
en_US.UTF8
). - Laden Sie die Daten neu.
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.
- 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.- 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
auftrue
, wenn das Abo sofort deaktiviert werden muss. Standardmäßig ist der Wertfalse
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)
- 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=>
- Deaktivieren Sie das Abo und trennen Sie das Replikat vom Anbieter. Führen Sie dazu den folgenden Befehl aus:
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:
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.ALTER EXTENSION postgis UPDATE TO '3.1.7';
- 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.
- 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 Wertt
bedeutet, dass dies zulässig ist. Der Wertf
gibt an, dass keine Verbindung hergestellt werden kann. - 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
-
Wechseln Sie in der Google Cloud Console zur Seite Cloud SQL-Instanzen.
- Klicken Sie auf den Instanznamen, um die Übersichtsseite einer Instanz zu öffnen.
- Klicken Sie auf Bearbeiten.
- Klicken Sie im Abschnitt Instanzinformationen auf die Schaltfläche Upgrade und bestätigen Sie, dass Sie die Seite "Upgrade" aufrufen möchten.
- 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.
- Klicken Sie auf Weiter.
- Geben Sie im Feld Instanz-ID den Namen der Instanz ein und klicken Sie dann auf die Schaltfläche Upgrade starten.
Prüfen Sie, ob die Hauptversion der aktualisierten Datenbank unter dem Instanznamen auf der Seite Übersicht der Instanz angezeigt wird.
gcloud
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.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
Ü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
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.
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
Ü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.
Ä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
- Rufen Sie Cloud Shell auf.
-
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).
-
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 alsmain.tf
bezeichnet.mkdir DIRECTORY && cd DIRECTORY && touch main.tf
-
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.
- Prüfen und ändern Sie die Beispielparameter, die auf Ihre Umgebung angewendet werden sollen.
- Speichern Sie die Änderungen.
-
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
-
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.
-
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.
- Ö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:
- Um den Löschschutz zu deaktivieren, setzen Sie in der Terraform-Konfigurationsdatei das Argument
deletion_protection
auffalse
.deletion_protection = "false"
- 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
-
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:
- Aktivieren Sie die Replikation von
pglogical
, wenn Ihre Instanz sie vor dem Upgrade verwendet hat. Dadurch wird automatisch der erforderliche Replikations-Slot erstellt.- 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
- 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
- Prüfen Sie den Status des Abos mit folgendem Befehl:
SELECT * FROM pglogical.show_subscription_status('test_sub');
- Testen Sie die Replikation, indem Sie Schreibtransaktionen ausführen und prüfen, ob die Änderungen am Ziel sichtbar sind.
- Löschen Sie das Abo
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.
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.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:
-
Wechseln Sie in der Google Cloud Console zur Seite Cloud SQL-Instanzen.
- Klicken Sie auf den Instanznamen, um die Übersichtsseite einer Instanz zu öffnen.
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.
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 Projektbuylots
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 DatentypUNKNOWN
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 DatentypSQL_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 DatentypREG*
aufgelistet werden (z. B.REGCOLLATION
oderREGNAMESPACE
). 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:
- Entfernen Sie die Erweiterungen
pg_stat_statements
undpgstattuple
. - Führen Sie das Upgrade aus.
- 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:
Ermitteln Sie die Sicherung vor dem Upgrade.
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.
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.
Fügen Sie die Lesereplikate hinzu.
Wenn Sie Lesereplikate verwendet haben, fügen Sie sie einzeln hinzu.
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.
- 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 beispielsweisemd5
. Wenn Sie ein Upgrade auf PostgreSQL 14 durchführen, ändert sich der Standardwert dieses Flags inscram-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
- Informationen über die Verbindungsoptionen einer Instanz
- Weitere Informationen über das Importieren und Exportieren von Daten
- Datenbank-Flags festlegen