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-kompatibel überprüfen.

Lösung

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

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 Wartungsaktivitäten psuchen

Amazon RDS verwendet automatisch Engine-Versions-Upgrades, um ausstehende Wartungsaktivitäten, wie z. B. einen Betriebssystem (OS)-Patch, auf deine 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 für den Upgrade-Vorgang, da Amazon RDS nur ein inkrementelles Backup für das Upgrade 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, stufe deine Replikat-Instance hoch oder lösche sie. Erstelle dann die Lesereplikate erneut, nachdem das Upgrade abgeschlossen ist.

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 musst du zusätzliche Anforderungen und Prozesse befolgen.

Transaktionen mit langer Ausführungszeit oder hohe Workloads vor dem Upgrade schließen bzw. reduzieren

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 signaling functions (Server-Signalisierungsfunktionen) auf der PostgreSQL-Website.

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

Das Hilfsprogramm pg_upgrade kann rechenintensiv sein. Um Rechen-, Arbeitsspeicher- und freie Speicherkapazität zu überprüfen, empfiehlt es sich, vor dem Upgrade deiner 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 und Engine-Versionen 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 Aurora.

Um zu überprüfen, welche Engine-Versionen für ein Engine-Versions-Upgrade kompatibel sind, führe den folgenden describe-db-engine-versions-Befehl aus:

aws rds describe-db-engine-versions --engine postgres --engine-version your-version --query "DBEngineVersions[].ValidUpgradeTarget[].{EngineVersion:EngineVersion}" --output text

**Hinweis:Ersetze ** your-version durch deine Engine-Version.

Wenn deine aktuelle Version nicht kompatibel ist, empfiehlt es sich, auf die neueste Nebenversion zu aktualisieren. Oder du kannst ein Upgrade auf eine der anderen verfügbaren Upgrade-Versionen durchführen. Informationen zu Engine-Versions-Upgrades findest du unter Choosing a major version for an RDS for PostgreSQL upgrade (Eine Hauptversion für ein Upgrade für PostgreSQL auswählen).

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 die Referenztypen reg* Objektkennung (OID) verwenden. 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 (AWS 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 den Datentyp unbekannt nicht 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';

(RDS nur für PostgreSQL) Nach einem Lesereplikat-Upgrade-Fehler suchen

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 auch nach der Wartezeit nicht zur primären DB-Instance aufschließen.
• 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.

Sicherstellen, 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.

Deine Erweiterungen vor dem Upgrade aktualisieren

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 unter Umständen die folgende Fehlermeldung:

„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 ANDname 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-kompatiblen DB-Clustern.

Im Systemkatalog der Version nach Änderungen suchen, die Probleme in den Ansichten verursachen

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

„pg_restore: error: could not execute query: ERROR: column reference 'backend_type' is ambiguous“

Dieser Fehler tritt auf, wenn du versuchst, die Datenbank von Version 12.x auf 13.x zu aktualisieren, und ** pg\ _stat\ _activity ** in Version 12.x und 13.x unterschiedliche Strukturen hat.

Gehe wie folgt vor, um dieses Problem zu beheben:

1. Führe den folgenden Befehl aus, um die Ansichtsdefinition abzufragen:

   SELECT pg_get_viewdef('pg_stat_activity_allusers', true);

2. Führe den folgenden Befehl aus, um die Ansicht zu löschen:

   DROP VIEW pg_stat_activity_allusers;

3. Aktualisiere die Engine-Version.

4. Führe den folgenden Befehl aus, um die Ansicht neu zu erstellen:

   CREATE VIEW pg_stat_activity_allusers AS SELECT * FROM get_sa();
   GRANT SELECT ON pg_stat_activity_allusers TO public;

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

Dieser Fehler tritt auf, wenn sich die Struktur des pg_constraint-Katalogs in PostgreSQL Version 12 geändert hat.

Um dieses Problem zu beheben, lösche die Ansichten, die auf den Systemkatalogen der Zielversion basieren.

**Wichtig:**Bevor du die Ansichten löschst, empfiehlt es sich, pgdump zu verwenden, um die Ansichten zu sichern oder die Definition der Ansichten zu erfassen. Wenn du eine Ansicht löschst, musst du oder muss der Datenbankadministrator die Ansicht nach dem Versions-Upgrade manuell neu erstellen.

Nach Fremdtabellen mit einem Prefetch-Wert suchen

Verwende die Erweiterung oracle\ _fdw, um zwischen 0 und 10.240 Zeilen aus Oracle-Datenbanken vorab abzurufen. Stelle den Prefetch-Parameter in der OPTIONS-Klausel der Fremdtabelle ein. Höhere Werte verbessern die Leistung, verbrauchen jedoch mehr Speicher auf dem PostgreSQL-Server. Um den Speicherverbrauch zu reduzieren, empfiehlt es sich, Prefetch während der Precheck-Phase eines Hauptversionsupgrades festzulegen.

Wenn der Prefetch-Wert größer als 1.000 ist, wird möglicherweise die folgende Fehlermeldung angezeigt:

„pg_restore: error: could not execute query: ERROR: invalid value for option 'prefetch'“

Hinweis: Gültige Werte in diesem Kontext sind Ganzzahlen zwischen 0 und 1000.

Um das Problem zu beheben, stelle für die Prefetch-Werte auf allen Fremdtabellen einen Wert zwischen 1 und 1.000 ein und versuche dann erneut, das Upgrade durchzuführen.

Führe den folgenden Befehl aus, um die Fremdtabellen zu ändern:

ALTER FOREIGN TABLE dwh_ddl_sync.fdw_all_tab_cols OPTIONS (SET prefetch '999');

Führe den folgenden Befehl aus, um alle Fremdtabellen aufzulisten:

SELECT * from information_schema.foreign_tables;

Führe den folgenden Befehl aus, um den Prefetch-Wert der Tabellen zu überprüfen:

SELECT * FROM pg_foreign_table;

Sicherstellen, dass du deinen Babelfish for Aurora PostgreSQL-kompatiblen Cluster aktualisiert hast

Wenn du ein Upgrade der Hauptversion der Engine auf einem PostgreSQL-kompatiblen Cluster mit Babelfish for Aurora durchführst, erhältst du möglicherweise eine Fehlermeldung, die der folgenden ähnelt:

„You can't perform a multi major version upgrade on a Babelfish for Aurora PostgreSQL DB cluster 13.20 and lower versions.“

Um dieses Problem zu beheben, aktualisiere den Cluster auf eine Version, die das Upgrade der Hauptversion unterstützt, und führe dann ein Upgrade auf die nächste Hauptversion durch.

Nach Abschluss des Upgrades

Führe nach Abschluss des Upgrades den Befehl ANALYZE für alle Benutzerdatenbanken aus, um die Tabelle pg\ _statistics zu aktualisieren. Bei größeren Versionsupgrades werden die Tabelleninhalte von pg\ _statistics nicht auf die neue Version migriert. Wenn du den Inhalt nicht verschiebst, haben Abfragen möglicherweise langsame Ausführungszeiten.

Weitere Informationen

Übersicht über die Upgrade-Prozesse für Aurora-PostgreSQL

Best practices for upgrading Amazon RDS to major and minor versions of PostgreSQL (Bewährte Methoden für das Upgrade von Amazon RDS auf Haupt- und Nebenversionen von PostgreSQL)