Zu prüfende Erweiterungen und Objekte der logischen Replikation

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

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 Serverkomponenten, 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 “. Erstellen Sie es nach dem Upgrade auf „ PostgreSQL s 18“ NICHT 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 Replikationsslots 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 die Anwendung, die den Replikations-Slot nutzt.
3. Die Replikationsslots löschen:

SELECT pg_drop_replication_slot('your_slot_name');

Nach dem Upgrade können Sie die Replikationsslots nach Bedarf neu erstellen. 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

Entfernen 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, sind noch einige weitere Schritte erforderlich.

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

1. Entfernen Sie alle Maskierungsregeln (falls aktiviert).

   SELECT anon.remove_masks_for_all_columns();
   

2. Deaktivieren Sie maskierte Rollen (das Upgrade kann fehlschlagen, wenn Rollen als maskiert markiert sind).

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

3. Lassen Sie die Erweiterung anon mit der Option "Kaskade" weg.

   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. Aktivieren Sie nach Abschluss der Aktualisierung die Erweiterung anon wieder und wenden Sie die Maskierungsregeln erneut an.

Es wird dringend empfohlen, die Daten sowohl vor als auch nach dem Löschen der Erweiterung zu validieren, um die Konsistenz der Maskierung vor der Aktualisierung sicherzustellen.

PostGIS

Wenn Sie PostGIS, verwenden, aktualisieren Sie zunächst PostGIS, bevor Sie PostgreSQL aktualisieren.

SELECT postgis_extensions_upgrade();

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

SELECT postgis_full_version();

Logical replication slots

Löschen Sie vor dem Upgrade alle logischen Replikations-Slots und erstellen Sie sie 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>');

Vorbereitende Schritte

Berücksichtigen Sie die folgenden Aspekte, bevor Sie mit dem Upgrade-Vorgang beginnen.

• Überprüfen Sie, ob für Ihre Bereitstellungsversion ein Versions-Upgrade verfügbar ist, indem Sie die Informationen zur Bereitstellungskapazität über die Benutzeroberfläche, die API, die CLI oder Terraform abrufen.

  Beispiel: Abrufen von Informationen zum Versions-Upgrade über die Befehlszeile:

  ibmcloud cdb capability-show versions postgresql
  

• Bitte lesen Sie die Anforderungen bezüglich der Vorabprüfung in diesem Abschnitt durch, bevor Sie die IPU auslösen. IPU wird direkt auf der Quellumgebung ausgeführt und erstellt keine neue Instanz. Zur Sicherheit der Kunden führt der Dienst vor Beginn des Upgrades Vorabprüfungen durch und blockiert den Vorgang, falls ein Risiko festgestellt wird. Überprüfen Sie insbesondere folgende Punkte:

  • Ihre Deployment-Gruppe umfasst höchstens 3 Mitglieder.
  • Ihre Bereitstellung befindet sich in einem einwandfreien Zustand.
  • In Ihrer Bereitstellung sind mindestens 10 % freier Speicherplatz verfügbar. Die standardmäßig maximal zulässige Festplattenauslastung für IPU-Vorabprüfungen beträgt 90 %.
  • Ihre Bereitstellung ist keiner hohen I/O-Belastung ausgesetzt. Die standardmäßig maximal zulässige E/A-Auslastung für die IPU-Vorabprüfung beträgt 90 %.
  • Die Größe Ihres Schemas und die Anzahl der Objekte liegen innerhalb der standardmäßigen Schwellenwerte für die Vorabprüfung. Standardmäßig darf kein einzelnes Schema größer als 100 GB sein, und die Gesamtzahl der Indizes und Sequenzen muss unter 50.000 bleiben.
  • Sie haben vor dem Upgrade alle erforderlichen Bereinigungen der Erweiterungs- und logischen Replikationsslots durchgeführt.

• Jede Hauptversion enthält einige Funktionen, die möglicherweise nicht abwärtskompatibel mit früheren Versionen sind. Lesen Sie die Versionshinweise des Datenbankanbieters, um sich über Änderungen zu informieren, die sich auf Ihre Anwendungen auswirken könnten.

• Das Herabstufen einer Bereitstellung auf eine frühere Version wird nicht unterstützt.

• Ein Major-Version-Upgrade vor Ort kann nach seinem Start nicht mehr abgebrochen werden.

• Falls Sie keine aktuelle Sicherung haben, sollten Sie vor dem Upgrade eine erstellen.

Beachten Sie außerdem, dass Ihre Datenbank nach Abschluss des Upgrades mit einer neuen Hauptversion von „ PostgreSQL “ läuft. Da „ PostgreSQL “ Daten in versionsspezifischen Formaten speichert, gehören Backups und PITR-Punkte aus der Zeit vor dem Upgrade zur Zeitachse der früheren Version und können nicht in die aktualisierte Version wiederhergestellt werden. Um die vollständigen Wiederherstellungs- und PITR-Funktionen (Point-in-Time Recovery) für die neue Version zu gewährleisten, führen Sie unmittelbar nach Abschluss des Upgrades eine neue Sicherung durch. Dieses Backup dient als Ausgangsbasis für künftige Wiederherstellungsvorgänge auf der Zeitachse der neuen Version.

Sollte IPU fehlschlagen, können gültige Backups aus der Zeit vor dem Upgrade weiterhin mit PITR verwendet werden, um die frühere Version von „ PostgreSQL “ auf einer neuen Instanz wiederherzustellen.

Fehlerbehebung

Wenn Ihre Anwendungen nach einem erfolgreichen In-Place-Upgrade auf eine Hauptversion unerwartete Probleme aufweisen und Sie zur vorherigen PostgreSQL Version zurückkehren müssen, wenden Sie sich bitte an unser Support-Team, um weitere Anweisungen zu erhalten. Vermeiden Sie es, selbst einen PITR-Vorgang zu starten oder ein Backup wiederherzustellen, da dies die Wiederherstellung erschweren kann.

Ein umfangreiches Upgrade vor Ort wird erst durchgeführt, wenn alle Vorabprüfungen erfolgreich abgeschlossen wurden. Diese Sicherheitsvorkehrungen dienen dem Schutz Ihrer Bereitstellung, da das Upgrade direkt auf der Quellinstanz durchgeführt wird. Wenn das Upgrade blockiert ist, überprüfen Sie die folgenden Bereiche:

• Anzahl der Knoten: Das In-Place-Upgrade auf eine höhere Hauptversion unterstützt Bereitstellungen mit maximal 3 Knoten. Wenn Ihre Bereitstellung mehr als 3 Mitglieder umfasst, verhindern die Vorabprüfungen das Upgrade. Mitglieder können nicht durch horizontale Skalierung entfernt werden. Eröffnen Sie daher ein Support-Ticket unter IBM Cloud, um die Anzahl der Mitglieder zu reduzieren, bevor Sie das Upgrade erneut versuchen.
• Cluster-Status: Stellen Sie sicher, dass der Patroni-Cluster fehlerfrei ist und ein eindeutiger Leader-/Replica-Status vorliegt. Upgrades können nicht durchgeführt werden, wenn Patroni Instabilität oder Failover-Bedingungen meldet.
• Speicherplatz: Stellen Sie sicher, dass genügend freier Speicherplatz vorhanden ist. Der Prozess verwendet pg_upgrade den Link-Modus, der einen ausreichenden Headroom erfordert. Wenn die Festplattennutzung den konfigurierten Grenzwert überschreitet (Standard: 90 %), wird vor einem erneuten Versuch freier Speicherplatz geschaffen.
• Festplatten-E/A-Auslastung: Überprüfen Sie die aktuelle E/A-Auslastung und die IOPS. Upgrades werden bei hoher Systemauslastung angehalten, um Leistungseinbußen oder Upgrade-Fehler zu vermeiden.
• Schema-Größe und Objektanzahl: Wie bereits erwähnt, wirkt sich die Schema-Größe direkt auf die Dauer eines In-Place-Upgrades auf eine höhere Hauptversion aus. Stellen Sie sicher, dass kein einzelnes Schema die maximale Größe (Standard: 100 GB) überschreitet und dass die Gesamtzahl der Index- und Sequenzobjekte unter dem Limit (Standard: 50.000) bleibt. Große Schemata oder ungewöhnlich hohe Objektzahlen erfordern möglicherweise eine Bereinigung oder Optimierung, bevor mit dem Upgrade fortgefahren werden kann. pg_upgrade führt schnelle Upgrades durch, indem neue Systemtabellen erstellt und die alten Benutzerdatendateien einfach wiederverwendet werden. Die zur Erstellung dieser Systemtabellen erforderliche Zeit hängt von der Anzahl der Datenbankobjekte ab. Der Ressourcenverbrauch kann mithilfe der Überwachungsintegration bewertet werden. Wenn nicht alle Datenbankkomponenten für ein Upgrade verfügbar sind, schlägt die Upgrade-Aufgabe fehl. Dies kann aufgrund von Wartungsarbeiten geschehen. Aufgaben, die aufgrund fehlgeschlagener Zustandsprüfungen fehlgeschlagen sind, können später erneut versucht werden. Wenn die Aufgabe weiterhin fehlschlägt, öffnen Sie ein Support-Ticket bei IBM Cloud support. Wenn bestimmte Überprüfungen für Ihre Umgebung nicht relevant sind und das Upgrade dennoch blockiert ist, erstellen Sie ein Support-Ticket, um weitere Unterstützung zu erhalten.

Probelauf von Hochstufung und Aktualisierung

Um die Auswirkungen größerer Versions-Upgrades zu bewerten, führen Sie einen Testlauf durch. Ein Probelauf simuliert die Hochstufung und das Upgrade, wobei die Ergebnisse in die Datenbankprotokolle ausgegeben werden. Greifen Sie über die Log-Analyse-Integration auf Ihre Datenbankprotokolle zu und zeigen Sie sie an. 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 wie folgt 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
    }
}' \