Zu prüfende Erweiterungen und Objekte der logischen Replikation

Überprüfen Sie vor dem Upgrade die folgenden Punkte:

Erweiterungen

• pg_repack
• old_snapshot
• wal2json
• anon
• PostGIS

Replikationsslots

• Logical replication slots

Anwendungsabhängigkeiten Wenn Sie Erweiterungen oder Replikationsobjekte entfernen, von denen Ihre Anwendungen abhängen, überprüfen Sie Ihre Datenflüsse und das Anwendungsverhalten, bevor Sie mit dem Upgrade fortfahren. Berücksichtigen Sie außerdem mögliche Störungen in Ihrer Anwendungslogik, die von bestimmten Funktionen von „ PostgreSQL “ abhängt.

pg_repack

Löschen Sie vor dem Upgrade den Ordner „ pg_repack “ und erstellen Sie ihn nach dem Upgrade neu. „ pg_repack “ verwendet eine versionsspezifische Erweiterung sowie Client- und Server-Komponenten, die mit der Hauptversion von „ PostgreSQL “ übereinstimmen müssen.

DROP EXTENSION pg_repack;

Erstellen Sie die Erweiterung nach dem Upgrade nur dann neu, wenn Ihre Arbeitslast sie weiterhin benötigt.

CREATE EXTENSION pg_repack;

old_snapshot

Löschen Sie vor dem Upgrade die Datei „ old_snapshot “. Nicht Erstellen Sie es nach dem Upgrade auf „ PostgreSQL “ 18 neu, da es nicht mehr unterstützt wird.

DROP EXTENSION old_snapshot;

wal2json Replikationsslots

Wenn Sie „ wal2json “ für die logische Dekodierung verwenden, müssen Sie vor dem Upgrade alle zugehörigen Replikationsslots löschen. Das Dienstprogramm „ pg_upgrade “ verbietet strikt Upgrades auf eine neue Hauptversion, solange Replikations-Slots vorhanden sind, und löst in diesem Fall einen kritischen Fehler aus, wodurch das Upgrade abgebrochen wird.

Vor dem Upgrade:

1. Stellen Sie sicher, dass alle ausstehenden WAL-Daten verarbeitet wurden.
2. Beenden Sie Ihre Anwendung, die den Replikations-Slot nutzt.
3. Die Replikations-Slots löschen:

SELECT pg_drop_replication_slot('your_slot_name');

Nach dem Upgrade können Sie die Replikationsslots nach Bedarf neu anlegen. Beachten Sie, dass „ wal2json “ nicht über CREATE EXTENSION installiert wird, sondern über Datenbankparameter (wal_level, max_replication_slots, max_wal_senders) und Tabellenberechtigungen konfiguriert wird, die Upgrades nicht verhindern.

anon

Deaktivieren Sie die Erweiterung „ anon “ vor dem Upgrade und aktivieren Sie sie nach dem Upgrade wieder, falls Sie sie weiterhin benötigen. Bevor Sie „ anon “ löschen können, sind noch weitere Schritte erforderlich.

Falls die Erweiterung „ anon “ installiert ist, befolgen Sie die nachstehenden Schritte und führen Sie die Befehle als Administrator aus, bevor Sie das Upgrade durchführen.

1. Entfernen Sie alle Maskierungsregeln (sofern aktiviert).

   SELECT anon.remove_masks_for_all_columns();
   

2. Maskierungsrollen deaktivieren (das Upgrade könnte fehlschlagen, wenn Rollen als maskiert markiert sind).

   SECURITY LABEL FOR anon ON ROLE <role_name> IS NULL;
   

3. Deaktivieren Sie die Erweiterung „ anon “ mit der Option „cascade“.

   DROP EXTENSION anon CASCADE;
   

4. Wenn die Erweiterung „ anon “ in mehreren Datenbanken innerhalb einer Instanz installiert ist, führen Sie die beschriebenen Schritte für jede Datenbank durch.

5. Nachdem das Upgrade abgeschlossen ist, aktivieren Sie die Erweiterung „ anon “ erneut und wenden Sie die Maskierungsregeln nach Bedarf erneut an.

Es wird dringend empfohlen, die Daten sowohl vor als auch nach dem Löschen der Erweiterung zu überprüfen, um vor der Durchführung des Upgrades die Konsistenz der Maskierung sicherzustellen.

PostGIS

Wenn Sie PostGIS, verwenden, führen Sie zunächst ein Upgrade von PostGIS durch, bevor Sie PostgreSQL aktualisieren.

SELECT postgis_extensions_upgrade();

Verwenden Sie die folgende Abfrage, um das Upgrade der Erweiterung „ PostGIS “ zu überprüfen.

SELECT postgis_full_version();

Logical replication slots

Löschen Sie vor dem Upgrade alle logischen Replikations-Slots und erstellen Sie diese nach dem Upgrade neu. Logische Slots sind an den Zustand des Quellservers gebunden und sollten auf der aktualisierten Instanz vollständig neu erstellt werden.

SELECT pg_drop_replication_slot('<slot_name>');

Logische Replikationsslots

Löschen Sie vor dem Upgrade alle logischen Replikations-Slots und erstellen Sie diese anschließend neu. Logische Replikations-Slots sind an den Zustand des Quellservers gebunden und müssen auf der aktualisierten Instanz neu erstellt werden.

SELECT pg_drop_replication_slot('<slot_name>');

Vorbereitende Schritte

Bitte beachten Sie Folgendes, bevor Sie mit dem Upgrade beginnen:

• Überprüfen Sie, ob Versions-Upgrades für Ihre Bereitstellung unterstützt werden, indem Sie die Benutzeroberfläche, die API, die Befehlszeilenschnittstelle oder Terraform verwenden.

  Beispiel (CLI):

  ibmcloud cdb capability-show versions postgresql
  

• Überprüfen Sie die Anforderungen für die Vorabprüfung. Das Upgrade wird auf der Quellumgebung ausgeführt und wird unterbrochen, wenn Risiken festgestellt werden. Stellen Sie sicher, dass:

  • Die Bereitstellung läuft reibungslos
  • Es sind mindestens 10 % freier Speicherplatz verfügbar
  • Die I/O-Auslastung liegt unter 90 %
  • Die Schema-Größe und die Anzahl der Objekte liegen innerhalb der zulässigen Grenzen
  • Die erforderliche Bereinigung der Erweiterungen und logischen Replikationsslots ist abgeschlossen

• Lesen Sie den Bericht „ https://www.postgresql.org/docs/release/ “, um sich über Kompatibilitätsänderungen zu informieren, die sich möglicherweise auf Ihre Anwendungen auswirken könnten.

• Ein Downgrade auf eine frühere Version wird nicht unterstützt.

• Ein In-Place-Upgrade kann nach seinem Start nicht mehr abgebrochen werden.

• Stellen Sie sicher, dass vor dem Upgrade eine aktuelle Sicherung verfügbar ist.

Gen2 beginnt mit „ PostgreSQL “ 18. Upgrade-Pfade zu neueren Versionen werden hinzugefügt, sobald diese unterstützt werden. Informationen zu früheren Versionen (14–17) finden Sie unter /docs/databases-for-postgresql?topic=databases-for-postgresql-upgrading.

Nach Abschluss des Upgrades läuft Ihre Bereitstellung mit einer neuen Hauptversion von „ PostgreSQL “. Backups und PITR-Punkte aus der Zeit vor dem Upgrade gehören zur Zeitachse der früheren Version und können nicht in die aktualisierte Version wiederhergestellt werden.

Um die Wiederherstellungs- und PITR-Funktionen für die neue Version aufrechtzuerhalten, erstellen Sie unmittelbar nach dem Upgrade ein Backup. Diese Sicherung dient als Ausgangsbasis für künftige Wiederherstellungsvorgänge.

Sollte das Upgrade fehlschlagen, können Backups aus der Zeit vor dem Upgrade weiterhin mit PITR verwendet werden, um die frühere Version in einer neuen Bereitstellung wiederherzustellen.

Fehlerbehebung

Sollten nach einem erfolgreichen Upgrade Probleme auftreten und Sie zur vorherigen Version zurückkehren müssen, wenden Sie sich bitte an den Support unter IBM Cloud®, um weitere Anweisungen zu erhalten. Führen Sie PITR-Vorgänge oder Wiederherstellungen nicht ohne Anleitung durch, da dies die Wiederherstellung erschweren kann.

Upgrades werden erst ausgeführt, nachdem alle Vorabprüfungen erfolgreich abgeschlossen wurden. Falls das Upgrade blockiert ist, überprüfen Sie Folgendes:

• Cluster-Zustand (Patroni-Status ist stabil)
• Ausreichend freier Speicherplatz
• Akzeptable Auslastung der Festplatten-E/A
• Beschränkungen hinsichtlich der Schema-Größe und der Objektanzahl

Große Schemata und eine hohe Anzahl von Objekten können die Dauer des Upgrades verlängern.

Sollten die Upgrade-Versuche weiterhin fehlschlagen, erstellen Sie bitte ein Support-Ticket unter https://cloud.ibm.com/login?redirect=%2Funifiedsupport%2Fsupportcenter.

Probelauf von Hochstufung und Aktualisierung

Um die Auswirkungen größerer Versions-Upgrades zu bewerten, führen Sie einen Testlauf durch. Ein Testlauf simuliert die Beförderung und die Höherstufung, wobei die Ergebnisse in die Datenbankprotokolle geschrieben werden. Über die Integration „Protokollanalyse“ können Sie auf Ihre Datenbankprotokolle zugreifen und diese einsehen. Dadurch wird sichergestellt, dass die von Ihnen derzeit verwendete Version mit ihren Erweiterungen erfolgreich auf die von Ihnen gewünschte Version aktualisiert werden kann.

Für den Probelauf wird für skip_initial_backup der Wert false festgelegt und es wird ein Wert für version definiert.

Der Befehl sieht folgendermaßen aus:

curl -X POST \
  https://api.{region}.databases.cloud.ibm.com/v5/ibm/deployments/{id}/remotes/promotion \
  -H 'Authorization: Bearer <>'  \
 -H 'Content-Type: application/json' \
 -d '{
    "promotion": {
        "version": "14",
        "skip_initial_backup": false,
        "dry_run": true
    }
}' \