Wie behebe ich Probleme mit Hauptversions-Upgrades in Amazon RDS für PostgreSQL oder Aurora PostgreSQL-Compatible?

Kurzbeschreibung

Nebenversions-Upgrades sind mit den früheren und späteren Nebenversionen derselben Hauptversion kompatibel. Hauptversions-Upgrades enthalten jedoch Datenbankänderungen, die mit vorhandenen Anwendungen nicht abwärtskompatibel sind. Diese Upgrades können das interne Format von Systemtabellen, Datendateien und Datenspeichern ändern. Amazon RDS verwendet pg_upgrade, um Hauptversions-Upgrades durchzuführen. Weitere Informationen findest du unter pg_upgrade auf der PostgreSQL-Website.

Während eines Hauptversions-Upgrades führt Amazon RDS ein Vorabprüfungsverfahren durch, das Probleme identifiziert, die dazu führen könnten, dass das Upgrade fehlschlägt. Es sucht in allen Datenbanken nach möglichen inkompatiblen Bedingungen. Wenn Amazon RDS während des Vorabprüfungsprozesses ein Problem feststellt, erstellt es ein Protokollereignis für die fehlgeschlagene Vorabprüfung. Die Protokollereignisse enthalten den Dateinamen, den Zeitstempel und die Gründe für das Fehlschlagen des Upgrades. Informationen zum Vorabprüfungsprozess für alle Datenbanken findest du im Protokoll pg_upgrade_precheck.log. Bei Engine-spezifischen Problemen musst du jedoch die Datenbank-Protokolldateien für Amazon RDS für PostgreSQL oder für Aurora PostgreSQL überprüfen.

Lösung

Das Hilfsprogramm pg_upgrade, das Hauptversions-Upgrades durchführt, erzeugt zwei Protokolle: pg_upgrade_internal.log und pg_upgrade_server.log. Amazon RDS hängt einen Zeitstempel an den Dateinamen dieser Protokolle an. In diesen Protokollen findest du weitere Informationen zu den Problemen und Fehlern, die während des Upgrades aufgetreten sind. Weitere Informationen findest du unter Überwachen von Amazon RDS-Protokolldateien oder Überwachen von Amazon Aurora-Protokolldateien.

Das Upgrade dauert lange

Suche nach ausstehenden Wartungsarbeiten

Amazon RDS verwendet automatisch Engine-Versions-Upgrades, um ausstehende Wartungsaktivitäten, wie z. B. einen Betriebssystem (OS)-Patch, auf deiner RDS-Instance anzuwenden. Amazon RDS wendet zuerst die ausstehende Aktivität an und aktualisiert dann die Engine-Version. Wenn Amazon RDS Wartungsaktivitäten am Betriebssystem durchführen muss, dauert das Upgrade länger.

Wenn sich deine RDS-Instance in einer Multi-AZ-Bereitstellung befindet, führt die Betriebssystemwartung zu einem Failover. Wenn du deine Instance in Multi-AZ einrichtest, erstellt Amazon RDS in der Regel das Backup der Instance auf der sekundären Instance. Bei einem Failover erstellt Amazon RDS nach dem Upgrade ein Backup auf einer neuen sekundären Instance. Dieses Backup auf der neuen sekundären Instance ist möglicherweise nicht das neueste Backup, daher führt Amazon RDS ein vollständiges Backup statt eines inkrementellen Backups durch. Ein vollständiges Backup kann lange dauern, insbesondere wenn die Datenbank groß ist.

Um dieses Problem zu vermeiden, suche nach ausstehenden Wartungsaktivitäten für deine RDS-DB-Instance oder für deine Aurora-DB-Instance. Oder führe den folgenden Befehl describe-pending-maintenance-actions der AWS Command Line Interface (AWS CLI) auf deiner Instance aus:

aws rds describe-pending-maintenance-actions --resource-identifier example-arn

Hinweis: Ersetze example-arn durch deinen DB-Instance-ARN. Wenn du beim Ausführen von AWS CLI-Befehlen Fehler erhältst, findest du weitere Informationen unter Problembehandlung bei der AWS CLI. Stelle außerdem sicher, dass du die neueste Version der AWS CLI verwendest.

Schließe ausstehende Wartungsaktivitäten ab, bevor du die Versions-Upgrades der Datenbank-Engine durchführst.

Vor dem Upgrade einen Snapshot erstellen

Es empfiehlt sich, vor dem Upgrade der Version einen Snapshot der RDS-DB-Instance oder des Aurora-DB-Clusters zu erstellen. Wenn du für die Instance bereits Backups aktiviert hast, erstellt Amazon RDS im Rahmen des Upgrade-Vorgangs automatisch einen Snapshot. Mit einem Snapshot reduzierst du die Zeit des Upgrade-Vorgangs, da Amazon RDS im Rahmen des Upgrades nur ein inkrementelles Backup erstellen muss.

Warten, bis das Lesereplikat aktualisiert ist

Wenn du ein Hauptversions-Upgrade der primären DB-Instance durchführst, aktualisiert Amazon RDS automatisch alle Lesereplikate in derselben AWS-Region. Nach dem Start des Upgrade-Workflows warten die Lesereplikate darauf, bis pg_upgrade auf der primären DB-Instance erfolgreich abgeschlossen wurde. Anschließend wartet das primäre DB-Instance-Upgrade darauf, dass die Upgrades der Lesereplikate abgeschlossen sind. Es kommt zu einem Ausfall, bis alle Upgrades abgeschlossen sind. Wenn das Ausfallzeitfenster für das Upgrade klein ist, stufe deine Replikat-Instance hoch oder lösche sie und erstelle Lesereplikate nach Abschluss des Upgrades neu.

Bei Aurora-DB-Clustern aktualisiert pg_upgrade zuerst die Schreiber-Instance. Dann kommt es bei jeder Leser-DB-Instance zu einem Ausfall, da pg_upgrade sie auf die neue Hauptversion aktualisiert. Beachte, dass es beim Upgrade einer globalen Aurora-Datenbank zusätzliche Anforderungen und Prozesse gibt.

Transaktionen mit langer Ausführungszeit oder hohe Workloads vor dem Upgrade regeln

Transaktionen mit langer Ausführungszeit oder hohe Workloads können die Zeit verlängern, die Amazon RDS benötigt, um die Datenbank herunterzufahren und die Datenbank-Engine zu aktualisieren.

Führe die folgende Abfrage aus, um Transaktionen mit langer Ausführungszeit zu identifizieren:

SQL>SELECT pid, datname, application_name, state, age(query_start, clock_timestamp()), usename, query
FROM pg_stat_activity
WHERE query NOT ILIKE '%pg_stat_activity%' AND
usename!='rdsadmin'
ORDER BY query_start desc;

Wenn du eine Abfrage mit langer Ausführungszeit identifizierst, verwende pg_cancel_backend oder pg_terminate_backend, um die Abfrage zu beenden. Weitere Informationen zu diesen Funktionen findest du unter 9.28.2. Server-Signalisierungsfunktionen.

Sicherstellen, dass du über genügend Rechenkapazität verfügst

Das Hilfsprogramm pg_upgrade kann rechenintensiv sein. Es empfiehlt sich, vor dem Upgrade deiner Produktionsdatenbanken ein Dry-Run-Upgrade durchzuführen, um sicherzustellen, dass du über genügend Rechen- oder Speicherkapazität verfügst. Das Dry-Run-Upgrade überprüft auch, ob möglicherweise Fehler bei der Vorabprüfung oder beim Upgrade auftreten. Du kannst einen Snapshot der Produktions-Instance wiederherstellen und einen Dry Run mit derselben Instance-Klasse wie jener der Produktionsdatenbank durchführen.

Das Upgrade schlägt fehl

Nach nicht unterstützten DB-Instance-Klassen suchen

Wenn die Instance-Klasse der DB-Instance nicht mit der PostgreSQL-Version kompatibel ist, auf die du ein Upgrade durchführst, schlägt das Upgrade fehl. Überprüfe die Kompatibilität der Engine-Version mit der Instance-Klasse für Amazon RDS oder für Amazon Aurora.

Nach offenen vorbereiteten Transaktionen suchen

Wenn in der Datenbank offene vorbereitete Transaktionen vorhanden sind, schlägt das Upgrade fehl. In der Datei pg_upgrade.log wird der Fehler There are uncommitted prepared transactions angezeigt. Bestätige alle geöffneten vorbereiteten Transaktionen oder setze sie zurück, bevor du ein Upgrade startest.

Um zu überprüfen, ob auf deiner Instance offene vorbereitete Transaktionen vorhanden sind, führe die folgende Abfrage aus:

SELECT count(*) FROM pg_catalog.pg_prepared_xacts;

Sicherstellen, dass du einen unterstützten Datentyp verwendest

Du kannst die Version nur für die Datentypen regclass, regrole und regtype aktualisieren. Das Hilfsprogramm pg_upgrade kann keine Datenbanken aktualisieren, die Tabellenspalten enthalten, die jene Typen verwenden, die die reg* Objekterkennung (OID) referenzieren. Wenn du den Datentyp regcollation, regconfig, regdictionary, regnamespace, regoper, regoperator, regproc oder regprocedure verwendest, schlägt das Upgrade fehl.

Um dieses Problem zu beheben, entferne alle Verwendungen der reg*-Datentypen, mit Ausnahme von regclass, regrole und regtype, bevor du die Daten-Engine aktualisierst. Führe die folgende Abfrage aus, um in deinen Tabellen nach nicht unterstützten reg*-Datentypen zu suchen.

SELECT count(*) FROM pg_catalog.pg_class c, pg_catalog.pg_namespace n, pg_catalog.pg_attribute a  WHERE c.oid = a.attrelid
      AND NOT a.attisdropped
      AND a.atttypid IN ('pg_catalog.regproc'::pg_catalog.regtype,
                         'pg_catalog.regprocedure'::pg_catalog.regtype,
                         'pg_catalog.regoper'::pg_catalog.regtype,
                         'pg_catalog.regoperator'::pg_catalog.regtype,
                         'pg_catalog.regconfig'::pg_catalog.regtype,
                         'pg_catalog.regdictionary'::pg_catalog.regtype)
      AND c.relnamespace = n.oid
      AND n.nspname NOT IN ('pg_catalog', 'information_schema');

Nach logischen Replikationsslots suchen

Wenn deine Instance über logische Replikationsslots verfügt, kannst du die Instance nicht aktualisieren und erhältst die folgende Fehlermeldung in der Datei pg_upgrade.log:

„The instance could not be upgraded because one or more databases have logical replication slots. Please drop all logical replication slots and try again.“

Logische Replikationsslots werden in der Regel für die Migration von AWS Database Migration Service (AMS DMS) verwendet. Sie werden auch verwendet, um Tabellen aus Datenbanken auf Data Lakes, Business Intelligence-Tools und andere Ziele zu replizieren. Stelle sicher, dass du den Zweck der verwendeten logischen Replikationsslots kennst, um zu überprüfen, ob du sie löschen kannst. Wenn die logischen Replikationsslots verwendet werden, lösche sie nicht. Du musst mit dem Upgrade der Version warten, bis du die logischen Replikationsslots löschen kannst.

Wenn du die logischen Replikationsslots nicht benötigst, führe die folgenden Abfragen aus, um sie zu löschen:

SELECT * FROM pg_replication_slots;

SELECT pg_drop_replication_slot(slot_name);

Hinweis: Ersetze slot_name durch den Namen des logischen Replikationsslots.

Nach Speicherproblemen suchen

Wenn der Instance bei der Ausführung des pg_upgrade-Skripts der Speicherplatz ausgeht, schlägt das Upgrade fehl und du erhältst die folgende Fehlermeldung:

„pg_restore: [archiver (db)] Error while PROCESSING TOC: pg_restore: [archiver (db)] could not execute query: ERROR: could not create file "base/12345/12345678": No space keyword" left on device“

Um dieses Problem zu beheben, stelle sicher, dass die Instance über ausreichend freien Speicherplatz verfügt, bevor du das Upgrade startest.

Nach unbekannten Datentypen suchen

In PostgreSQL Versionen 10 und höher kannst du keine Datentypen unbekannt verwenden. Wenn beispielsweise eine PostgreSQL-Datenbank der Version 9.6 den Datentyp unbekannt verwendet, erhältst du beim Upgrade auf Version 10 die folgende Fehlermeldung:

„The instance could not be upgraded because the 'unknown' data type is used in user tables. Please remove all usages of the 'unknown' data type and try again.“

Um dieses Problem zu beheben, entferne manuell Spalten, die den Datentyp unbekannt verwenden, oder ändere sie in einen unterstützten Datentyp. Führe die folgende Abfrage aus, um die Spalten in deiner Datenbank zu finden, die den Datentyp unbekannt verwenden:

SELECT DISTINCT data_type FROM information_schema.columns WHERE data_type ILIKE 'unknown';

(nur RDS für PostgreSQL) Prüfen, ob ein Lesereplikat-Upgrade fehlgeschlagen ist

Wenn die PostgreSQL-Instance über Lesereplikate verfügt, können Fehler beim Lesereplikat-Upgrade dazu führen, dass das Upgrade der Primär-Instance hängen bleibt oder fehlschlägt. Amazon RDS versetzt ein fehlgeschlagenes Lesereplikat in den Statusincompatible-restore und stoppt dann die Replikation auf der DB-Instance.

Ein Lesereplikat-Upgrade kann aus einem der folgenden Gründe fehlschlagen:

• Das Lesereplikat kann die primäre DB-Instance auch nach der Wartezeit nicht nachholen.
• Das Lesereplikat befindet sich in einem terminalen oder inkompatiblen Lebenszyklusstatus, z. B. storage-full oder incompatible-restore.
• Wenn das Upgrade der primären DB-Instance gestartet wird, wird ein separates Nebenversions-Upgrade auf dem Lesereplikat ausgeführt.
• Das Lesereplikat verwendet inkompatible Parameter.
• Das Lesereplikat kann nicht mit der primären DB-Instance kommunizieren, um den Datenordner zu synchronisieren.

Lösche das Lesereplikat, um dieses Problem zu beheben. Erstelle dann nach dem Upgrade ein neues Lesereplikat, das auf der aktualisierten primären Instance basiert.

Sich vergewissern, dass dein primärer Benutzername korrekt ist

Wenn der primäre Benutzername mit pg_ beginnt, schlägt das Upgrade fehl und du erhältst die folgende Fehlermeldung:

„PreUpgrade checks failed: The instance could not be upgraded because one or more role names start with 'pg_'. Please rename all roles with names that start with 'pg_' and try again.“

Um dieses Problem zu beheben, erstelle einen weiteren Benutzer mit der Rolle rds_superuser, die nicht mit pg_ beginnt.

Nach inkompatiblen Parametern suchen

Der Fehler mit inkompatiblen Parametern tritt auf, wenn der Wert eines speicherbezogenen Parameters, wie shared_buffer oder work_memory, für deine Konfiguration zu hoch ist. Dieser Fehler führt dazu, dass das Upgrade-Skript fehlschlägt. Um das Problem zu beheben, reduziere die Werte dieser Parameter und führe dann das Upgrade erneut aus.

Aktualisierung der Erweiterungen vor dem Upgrade

Bei Hauptversions-Upgrades werden PostgreSQL-Erweiterungen nicht aktualisiert. Wenn du die Erweiterungen vor einem Upgrade der Hauptversion nicht aktualisierst, erhältst du in der Datei pg_upgrade.log eine Fehlermeldung, die dem folgenden Beispiel ähnelt:

„The Logs indicates that the RDS instance ''abcd'' has older version of PostGIS extension or its dependent extensions (address_standardizer,address_standardizer_data_us, postgis_tiger_geocoder, postgis_topology, postgis_raster) installed as against the current version required for the upgrade.“

Der vorherige Beispielfehler zeigt ein Problem mit der PostGIS-Erweiterung. Um dieses Problem zu beheben, führe die folgende Abfrage aus, um die Standardversionen und die installierten Versionen für PostGIS und die davon abhängigen Erweiterungen zu überprüfen:

SELECT name, default_version, installed_versionFROM pg_available_extensions WHERE installed_version IS NOT NULL AND
name LIKE 'postgis%' OR name LIKE 'address%';

Hinweis: Ersetze postgis% durch deine Erweiterung.

Wenn der Wert für installed_version niedriger als der Wert von default_version ist, musst du PostGIS auf die Standardversion aktualisieren. Führe die folgende Abfrage aus, um die Erweiterung zu aktualisieren:

ALTER EXTENSION extension_name UPDATE TO 'default_version_number';

Hinweis: Ersetze default_version_number durch den Wert default_version.

Weitere Informationen findest du unter Upgrades der RDS für PostgreSQL-DB-Engine oder Upgrade von Amazon Aurora PostgreSQL-DB-Clustern.

Nach Problemen in den Anzeigen suchen, die durch eine Änderung im Systemkatalog der Zielversion verursacht wurden

Die Spalten in bestimmten Anzeigen variieren je nach PostgreSQL-Version. Beispielsweise erhältst du möglicherweise eine Fehlermeldung, die dem folgenden Beispiel ähnelt:

„PreUpgrade checks failed: The instance could not be upgraded because one or more databases have views or materialized views which depend on 'pg_stat_activity'. Please drop them and try again.“

Dieser Fehler tritt auf, wenn du die Datenbank von Version 9.5 auf 9.6 aktualisierst. Im vorherigen Beispiel verursacht die Anzeige pg_stat_activity das Problem. In Version 9.6 ersetzte PostgreSQL die Spalte waiting durch die Spalten wait_event_type und wait_event.

Möglicherweise erhältst du auch eine Fehlermeldung, die dem folgenden Beispiel ähnelt:

„pg_restore: from TOC entry abc; abc abcd VIEW sys_user_constraints art pg_restore: error: could not execute query: ERROR: column c.consrc does not exist LINE 18: "c"."consrc" AS "search_condition", ^ HINT: Perhaps you meant to reference the column "c.conkey" or the column "c.conbin".“

In diesem Beispiel tritt der Fehler auf, weil sich die Struktur des pg_constraint-Katalogs in PostgreSQL Version 12 geändert hat.

Um diese Probleme zu beheben, lösche die Anzeigen, die auf den Systemkatalogen der Zielversion basieren.

Wichtig: Es ist eine bewährte Methode, pgdump zu verwenden, um deine Anzeigen zu sichern oder die Definition der Anzeige zu erfassen, bevor du sie löschst. Wenn du eine Anzeige löschst, musst du die Anzeige nach dem Versions-Upgrade manuell neu erstellen. Möglicherweise musst du mit dem Datenbank-Administrator zusammenarbeiten.

Nach dem Upgrade

Führe nach Abschluss des Upgrades ANALYZE für alle Benutzerdatenbanken aus, um die Tabelle pg_statistics zu aktualisieren. Bei einem größeren Upgrade wird der Inhalt der Tabelle pg_statistics nicht auf die neue Version verschoben. Wenn du den Inhalt nicht verschiebst, treten möglicherweise Abfragen mit langsamen Ausführungszeiten auf.

Ähnliche Informationen

Überblick über die Aurora PostgreSQL-Upgrade-Prozesse