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

Kurzbeschreibung

Hauptversions-Upgrades enthalten Datenbankänderungen, die mit vorhandenen Anwendungen nicht abwärtskompatibel sind. Die 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 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 das Protokoll pg_upgrade_internal.log und das Protokoll pg_upgrade_server.log. Amazon RDS hängt einen Zeitstempel an den Dateinamen der Protokolle an. Lies die Protokolle, um weitere Informationen zu den Problemen und Fehlern zu erhalten, die während des Upgrades auftreten. Weitere Informationen findest du unter Überwachen von Amazon RDS-Protokolldateien oder Überwachen von Amazon Aurora-Protokolldateien.

Lang andauernde Upgrades

Nach ausstehenden Wartungsarbeiten überprüfen

Wenn du beim Ausführen von AWS Command Line Interface (AWS CLI)-Befehlen Fehlermeldungen erhältst, findest du weitere Informationen dazu unter Problembehandlung bei AWS CLI-Fehlern. Stelle außerdem sicher, dass du die neueste Version der AWS CLI verwendest.

Amazon RDS verwendet automatisch Engine-Versions-Upgrades, um ausstehende Wartungsaktivitäten, wie z. B. einen Betriebssystem (OS)-Patch, auf deiner Amazon 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 die Amazon RDS-Instance in einer Multi-AZ-Bereitstellung befindet, führt die Betriebssystemwartung zu einem Failover. Wenn du deine Instance in einer Multi-AZ-Umgebung 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 AWS-CLI-Befehl describe-pending-maintenance-actions auf der Instance aus:

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

Hinweis: Ersetze example-arn durch deinen DB-Instance-ARN.

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

Einen Snapshot erstellen, bevor du ein Upgrade durchführst

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. Snapshots reduzieren 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. Die DB-Instance wird heruntergefahren, bis alle Upgrades abgeschlossen sind. Wenn das Ausfallzeitfenster für das Upgrade klein ist, dann 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 Writer-Instance. Dann wird jede Reader-DB-Instance heruntergefahren, wenn pg_upgrade sie auf die neue Hauptversion aktualisiert.

Hinweis: Wenn du ein Upgrade einer globalen Aurora-Datenbank durchführst, dann gibt es zusätzliche Anforderungen und Prozesse.

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 Transaktion mit langer Ausführungszeit identifizierst, verwende pg_cancel_backend oder pg_terminate_backend, um die Transaktion zu beenden. Weitere Informationen zu pg_cancel_backend und pg_terminate_backend findest du unter Server-Signalisierungsfunktionen auf der PostgreSQL-Website.

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

Das Hilfsprogramm pg_upgrade kann rechenintensiv sein. Um zu überprüfen, ob du über genügend Rechen- oder Speicherkapazität verfügst, empfiehlt es sich, vor dem Upgrade der Produktionsdatenbanken ein Test-Upgrade durchzuführen. Das Test-Upgrade überprüft auch, ob möglicherweise Fehler bei der Vorabprüfung oder beim Upgrade auftreten. Du kannst den Snapshot der Produktions-Instance wiederherstellen und einen Test mit derselben Instance-Klasse wie die Instance-Klasse der Produktionsdatenbank durchführen.

Upgrade-Fehler

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. Bevor du das Upgrade startest, bestätige alle geöffneten vorbereiteten Transaktionen oder setze sie zurück.

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;

Einen unterstützten Datentyp verwenden

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.“

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

Wenn du die logischen Replikationsslots nicht benötigst, führe die folgenden Befehle 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 „incompatible parameters“ 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 der 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 der folgenden ä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.“

Die vorherige Beispielfehlermeldung 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 für default_version ist, musst du PostGIS auf die Standardversion aktualisieren. Führe den folgenden Befehl 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.

Im Systemkatalog der Zielversion nach Änderungen suchen, die zu Problemen in den Anzeigen führen

Die Spalten in bestimmten Anzeigen variieren je nach PostgreSQL-Version. Zum Beispiel, erhältst du möglicherweise eine Fehlermeldung, die der folgenden ä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. In der vorherigen Beispielfehlermeldung 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.

Oder du erhältst eine Fehlermeldung, die der folgenden ä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".“

Die vorhergehende Beispielfehlermeldung zeigt, dass der Fehler aufgetreten ist, 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:**Bevor du die Anzeigen löschst, empfiehlt es sich, pgdump zu verwenden, um die Anzeigen zu sichern oder die Definition der Anzeigen zu erfassen. Wenn du eine Anzeige löschst, musst du oder der Datenbankadministrator die Anzeige nach dem Versions-Upgrade manuell neu erstellen.

Abschluss des Upgrades

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