Wie behebe ich Probleme mit wichtigen Versionsupgrades in Amazon RDS für PostgreSQL und Aurora für PostgreSQL?

Letzte Aktualisierung: 21.11.2022

Mein Engine-Versionsupgrade für Amazon Relational Database Service (Amazon RDS) für PostgreSQL oder Amazon Aurora-PostgreSQL-Compatible-Edition hängt oder ist fehlgeschlagen.

Kurzbeschreibung

Wenn Amazon RDS eine neue Version einer Datenbank-Engine unterstützt, können Sie Ihre DB-Instances auf die neue Version aktualisieren. Sie können eine Nebenversion oder ein Upgrade der Hauptversion für Ihre DB-Instances durchführen.

Die Upgrades von Nebenversionen werden verwendet, um Sicherheitslücken zu schließen und Fehler zu beheben. Diese Upgrades fügen normalerweise keine neuen Funktionen hinzu und ändern das interne Speicherformat nicht. Sie sind immer mit den früheren und späteren Nebenversionen derselben Hauptversion kompatibel. Wichtige Versionsupgrades enthalten jedoch Datenbankänderungen, die mit vorhandenen Anwendungen nicht rückwärtskompatibel sind. Diese Upgrades können das interne Format von Systemtabellen, Datendateien und Datenspeicher ändern. Amazon RDS verwendet das PostgreSQL-Dienstprogramm pg_upgrade, um größere Versionsupgrades durchzuführen.

Während eines Upgrades der Hauptversion einer PostgreSQL-Instance führt Amazon RDS ein Precheck-Verfahren durch. Dieses Verfahren identifiziert alle Probleme, die dazu führen könnten, dass das Upgrade fehlschlägt. Es prüft auf mögliche inkompatible Bedingungen in allen Datenbanken. Wenn Amazon RDS während des Vorprüfvorgangs ein Problem feststellt, erstellt es ein Protokollereignis für die fehlgeschlagene Vorabprüfung. Weitere Informationen zum Vorabprüfvorgang für alle Datenbanken finden Sie im Upgrade-Protokoll von pg_upgrade_precheck.log. Amazon RDS hängt einen Zeitstempel an den Dateinamen an. RDS-Ereignisse können auch die Gründe für den Fehlschlag des Upgrades angeben. Bei Problemen, die nur beim Modul vorkommen, müssen Sie jedoch die Datenbankprotokolldateien überprüfen.

Weitere Informationen finden Sie unter Datenbank-Logdateien anzeigen und aufführen für RDS für PostgreSQL. Oder siehe Datenbank-Logdateien für Aurora für PostgreSQL anzeigen und auflisten.

Während eines Upgrades der Hauptversion führt RDS diese Schritte aus:

  1. Erstellen Sie vor dem Upgrade einen Snapshot der Instance. Dies geschieht nur, wenn Sie den Aufbewahrungszeitraum für Backups für Ihre DB-Instance auf eine Zahl größer als Null festlegen.
  2. Fahren Sie die Instance herunter.
  3. Verwenden Sie das Dienstprogramm pg_upgrade, um die Upgrade-Aufgabe auf der Instance auszuführen.
  4. Erstellen Sie nach dem Upgrade einen Snapshot der Instance.

Lösung

Obwohl Amazon RDS diese Upgrades verwaltet, können bei einem Versionsupgrade die folgenden Probleme auftreten:

  • Das Upgrade dauert länger.
  • Das Upgrade schlägt fehl.

Das Upgrade dauert lange

Ausstehende Wartungsaktivitäten: Alle ausstehenden Wartungsaktivitäten werden automatisch bei Upgrades der Engine-Version angewendet. Dies kann das Anwenden eines Betriebssystem-Patches auf Ihrer RDS-Instance beinhalten. In diesem Fall wird zuerst der Betriebssystem-Patch angewendet, und dann wird die Engine-Version aktualisiert. Also führt die Durchführung von Wartungsaktivitäten für das Betriebssystem zu einer Verlängerung der Zeit, die für die Durchführung des Upgrades benötigt wird.

Wenn sich Ihre RDS-Instance in einer Multi-AZ-Bereitstellung befindet, führt die Wartung des Betriebssystems zu einem Failover. Wenn Sie Ihre Instance in Multi-AZ einrichten, wird das Backup für die Instance normalerweise auf der sekundären Instance erstellt. Im Falle eines Failovers wird nach dem Upgrade ein Backup auf einer neuen sekundären Instance erstellt. Dieses Backup auf der neuen sekundären Instance ist möglicherweise nicht das neueste Backup. Also kann anstelle eines inkrementellen Backups ein vollständiges Backup ausgelöst werden. Die Erstellung eines vollständigen Backups kann lange dauern, insbesondere wenn die Datenbank sehr groß ist.

Um dieses Problem zu vermeiden, suchen Sie im Abschnitt Pending maintenance (Ausstehende Wartungsaktivitäten) in Ihrer RDS-Konsole nach ausstehenden Wartungsaktivitäten. Informationen zu Aurora für PostgreSQL finden Sie unter Ausstehende Wartungsarbeiten anzeigen.

Oder verwenden Sie den Befehl des AWS Command Line Interfaces (AWS CLI) describe-pending-maintenance-actions für Ihre Instance.

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

Hinweise: Schließen Sie diese Wartungsaktivitäten ab, bevor Sie die Versionsupgrades der Datenbankengine durchführen.

Vor dem Upgrade wurde kein Snapshot erstellt: Es empfiehlt sich, vor der Durchführung des Upgrades einen Snapshot der RDS oder Aurora-für-PostgreSQL-Cluster-Snapshot zu erstellen. Wenn Sie bereits Backups für Ihre Instance aktiviert haben, wird im Rahmen des Upgrade-Vorgangs automatisch ein Snapshot erstellt. Das Erstellen eines Snapshots vor dem Upgrade reduziert die Zeit, die für den Abschluss des Upgrade-Vorgangs benötigt wird. Dies liegt daran, dass in diesem Fall während des Upgrade-Vorgangs nur ein inkrementelles Backup erstellt wird.

RDS-für-PostgreSQL-Lesereplikat-Upgrades: Wenn Sie ein Hauptversion-Upgrade Ihrer primären DB-Instance durchführen, werden alle Lesereplikate in derselben Region automatisch aktualisiert. Nachdem der Upgrade-Workflow gestartet wurde, warten die Lesereplikate darauf, dass pg_upgrade auf der primären DB-Instance erfolgreich abgeschlossen wurde. Anschließend wartet das Upgrade der primären Instance darauf, dass die Lesereplikat-Upgrades abgeschlossen werden. Es kommt zu einem Ausfall, bis alle Upgrades abgeschlossen wurden. Wenn das Ausfallzeitfenster für das Upgrade begrenzt ist, können Sie Ihre Replikat-Instance hochstufen oder löschen. Erstellen Sie dann die Lesereplikate erneut, nachdem das Upgrade abgeschlossen ist.

Um die DB-Instances, aus denen Ihr Cluster besteht, sicher zu aktualisieren, verwendet Aurora für PostgreSQL das Dienstprogramm pg_upgrade. Nach Abschluss des Schreiber-Upgrades kommt es bei jeder Leser-Instance zu einem kurzen Ausfall, während sie auf die neue Hauptversion aktualisiert wird.

Langfristige Transaktionen oder hohe Arbeitslast vor dem Upgrade: Langfristige Transaktionen oder eine hohe Workload, die vor dem Upgrade ausgeführt wird, können die Zeit zum Herunterfahren der Datenbank erhöhen und die Upgrade-Zeit verlängern.

Führen Sie diese Abfrage aus, um lang andauernde Transaktionen 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;

Unzureichende Rechenkapazität: Das Dienstprogramm pg_upgrade kann rechenintensiv sein. Also empfiehlt es sich, vor dem Upgrade Ihrer Produktionsdatenbanken ein Probe-Upgrade durchzuführen. Sie können einen Snapshot der Produktionsinstance wiederherstellen und einen Probelauf mit derselben Instance-Klasse wie die der Produktionsdatenbank durchführen.

Upgrade schlägt fehl

Nicht unterstützte DB-Instance-Klassen: Das Upgrade schlägt möglicherweise fehl, wenn die Instance-Klasse Ihrer DB-Instance nicht mit der PostgreSQL-Version kompatibel ist, auf die Sie ein Upgrade durchführen. Überprüfen Sie unbedingt die Kompatibilität der Instance-Klasse mit der Engine-Version. Weitere Informationen finden Sie in den unterstützten DB-Engines für DB-Instance-Klassen für RDS für PostgreSQL. Oder überprüfen Sie die unterstützten DB-Engines für DB-Instance-Klassen für Aurora für PostgreSQL.

Offene vorbereitete Transaktionen: Vorbereitete Transaktionen, die in der Datenbank geöffnet werden, können zu einem Upgrade-Fehler führen. Stellen Sie sicher, dass Sie alle offenen vorbereiteten Transaktionen bestätigen oder rückgängig machen, bevor Sie ein Upgrade starten.

Führen Sie diese Abfrage durch, um zu überprüfen, ob in Ihrer Instance offene vorbereitete Transaktionen vorhanden sind:

SELECT count(*) FROM pg_catalog.pg_prepared_xacts;

In diesem Fall sieht der Fehler in der Datei pg_upgrade.log etwa wie folgt aus:

------------------------------------------------------------------------
Upgrade could not be run on Wed Apr 4 18:30:52 2018
-------------------------------------------------------------------------
The instance could not be upgraded from 9.6.11 to 10.6 for the following reasons.
Please take appropriate action on databases that have usage incompatible with 
the requested major engine version upgrade and try the upgrade again.

*There are uncommitted prepared transactions. Please commit or rollback 
all prepared transactions.*

Nicht unterstützte Datentypen: Das Upgrade schlägt mit einem Fehler fehl, wenn Sie versuchen, die Datenbank mit nicht unterstützten Datentypen wie den folgenden zu aktualisieren:

  • regcollation
  • regconfig
  • regdictionary
  • regnamespace
  • regoper
  • regoperator
  • reproc
  • regprocedure

Hinweis: Die Datentypen regclass, regrole und regtype werden unterstützt.

Das PostgreSQL-Upgrade-Dienstprogramm pg_upgrade unterstützt kein Upgrade von Datenbanken, die Tabellenspalten enthalten, die die reg* OID-referenzierenden Systemdatentypen verwenden. Entfernen Sie alle Verwendungen von reg*-Datentypen außer regclass, regrole und regtype entfernen, bevor Sie ein Upgrade versuchen.

Führen Sie diese Abfrage aus, um die Verwendung nicht unterstützter reg*-Datentypen zu überprüfen:

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');

Logische Replikationsslots: Ein Upgrade kann nicht durchgeführt werden, wenn Ihre Instance über logische Replikationsslots verfügt. Logische Replikationsslots werden normalerweise für die Migration des AWS Database Migration Service (AMS DMS) verwendet. Sie werden auch für die Replikation von Tabellen aus Datenbanken auf Data Lakes, Business Intelligence-Tools und andere Ziele verwendet. Vergewissern Sie sich vor dem Upgrade, dass Sie den Zweck der verwendeten logischen Replikationsslots kennen, und vergewissern Sie sich, dass sie gelöscht werden können.

Wenn die logischen Replikationsslots noch verwendet werden, dürfen Sie sie nicht löschen. In diesem Fall können Sie mit dem Upgrade nicht fortfahren.

Der zugehörige Fehler in der pg_upgrade-Protokolldatei sieht wie dieses Beispiel aus:

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

Wenn die logischen Replikationsslots nicht benötigt werden, führen Sie diese Abfragen aus, um sie zu löschen:

SELECT * FROM pg_replication_slots;
SELECT pg_drop_replication_slot(slot_name);

Speicherprobleme: Während das pg_upgrade-Skript ausgeführt wird, geht der Instance möglicherweise der Speicherplatz aus. Dies führt dazu, dass das Skript fehlschlägt und eine Fehlermeldung ähnlich dieser angezeigt wird:

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, stellen Sie sicher, dass die Instance über ausreichend freien Speicherplatz verfügt, bevor Sie das Upgrade starten.

Unbekannte Datentypen: PostgreSQL-Versionen 10 und höher unterstützen keine unbekannten Datentypen. Wenn eine PostgreSQL-Version-9.6-Datenbank den unbekannten Datentyp verwendet, wird bei einem Upgrade auf Version 10 eine Fehlermeldung wie diese angezeigt:

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

Dies ist eine PostgreSQL-Einschränkung, und die RDS-Automatisierung ändert keine Spalten, die den unbekannten Datentyp verwenden. Möglicherweise müssen Sie diese Spalten vor dem Upgrade manuell ändern.

Führen Sie diese Abfrage aus, um Spalten in Ihrer Datenbank mit dem unbekanntem Datentyp zu finden:

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

Nachdem Sie die Spalten identifiziert haben, können Sie diese Spalten entfernen oder sie in einen unterstützten Datentyp ändern.

Fehler beim Lesereplikat-Upgrade (RDS nur für PostgreSQL): Die PostgreSQL-Instance verfügt über Lesereplikate. Fehler beim Lesereplikat-Upgrade können dazu führen, dass Ihr primäres Instance-Upgrade hängen bleibt. Ein Fehler beim Read-Replica-Upgrade kann auch zum Fehlschlag des Upgrades der primären Instance führen. Eine fehlgeschlagene Read Replica wird in den Status incompatible-restore versetzt, und die Replikation wird auf der DB-Instance gestoppt.

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

  • Das Lesereplikat konnte die primäre DB-Instance auch nach der Wartezeit nicht einholen.
  • Das Lesereplikat befindet sich in einem abschließenden oder inkompatiblen Lebenszyklusstatus, wie z. B. eine vollständige oder inkompatible Wiederherstellung.
  • Als das Upgrade der primären DB-Instance gestartet wird, wird ein separates Upgrade der Nebenversion 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.

Um dieses Problem zu beheben, löschen Sie das Lesereplikat. Erstellen Sie dann erneut ein Lesereplikat basierend auf der aktualisierten primären Instance neu erstellen, nachdem die primäre Instance aktualisiert wurde.

Falscher primärer Benutzername: Wenn der primäre Benutzername mit „pg_“ beginnt, schlägt das Upgrade fehl und die folgende Fehlermeldung wird angezeigt:

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 lösen, erstellen Sie einen anderen Benutzer mit der Rolle rds_superuser. Sie können sich an den AWS Support wenden, um diesen Benutzer als neuen primärer Benutzer zu aktualisieren.

Inkompatibler Parameterfehler: Dieser Fehler tritt auf, wenn ein speicherbezogener Parameter wie shared_buffer oder work_memory auf einen höheren Wert gesetzt wird. Dies kann dazu führen, dass das Upgrade-Skript fehlschlägt. Reduzieren Sie die Werte dieser Parameter, und führen Sie das Upgrade erneut aus, um das Problem zu beheben.

Erweiterungen wurden vor dem Upgrade nicht aktualisiert: Bei einem Hauptversion-Upgrade werden keine PostgreSQL-Erweiterungen aktualisiert. Wenn Sie die Erweiterungen nicht aktualisiert haben, bevor Sie ein Upgrade der Hauptversion durchgeführt haben, wird in der Datei pg_upgrade.log dieser Fehler angezeigt:

The Logs indicates that the RDS instance ''xxxx'' 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.

Diese Fehlermeldung weist auf ein Problem mit der PostGIS-Erweiterung hin.

Führen Sie in diesem Fall diese Abfrage aus, um die Standard- und installierten Versionen für PostGIS und seine abhängigen Erweiterungen zu überprüfen:

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

Wenn der Wert für installed_version kleiner ist als der von default_version, müssen Sie PostGIS auf die Standardversion aktualisieren. Führen Sie dazu diese Abfrage aus:

ALTER EXTENSION extension_name UPDATE TO 'default_version_number';

Weitere Informationen finden Sie unter PostgreSQL-Erweiterungen für RDS für PostgreSQL aktualisieren oder PostgreSQL-Erweiterungen für Aurora PostgreSQL aktualisieren.

Problem in Ansichten aufgrund einer Änderung im Systemkatalog der Zielversion: Die Spalten in den bestimmten Ansichten variieren zwischen verschiedenen PostgreSQL-Versionen.

Beispielsweise könnte eine Fehlermeldung wie diese angezeigt werden:

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 Sie die Datenbank von Version 9.5 auf 9.6 aktualisieren. Dieser Fehler wird durch die Ansicht pg_stat_activity verursacht, da die ausstehnde Spalte in Version 9.6 durch die Spalten wait_event_type und wait_event ersetzt wurde.

pg_restore: from TOC entry xxx; xxx xxxx 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, weil sich die Struktur des Katalogs pg_constraint in PostgreSQL-Version 12 geändert hat.

Sie können diese Probleme lösen, indem die auf Systemkatalogen der Zielversion basierenden Ansichten gelöscht werden.

Hinweis: Seien Sie vorsichtig, wenn Sie diese Ansichten löschen. Wenden Sie sich an Ihren DBA.

Andere Überlegungen

  • Das Dienstprogramm pg_upgrade 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 finden Sie weitere Informationen zu den Problemen und Fehlern, die während des Upgrades aufgetreten sind. Weitere Informationen finden Sie unter Überwachen von Amazon-RDS-Protokolldateien für RDS für PostgreSQL oder Überwachen von Amazon-Aurora-Protokolldateien für Aurora für PostgreSQL.
  • Wenn das Upgrade abgeschlossen wurde, führen Sie ein Upgrade der Tabelle pg_statistics durch, indem Sie ANALYZE für alle Benutzerdatenbanken ausführen. Bei einem größeren Upgrade wird der Inhalt der Tabelle pg_statistics nicht auf die neue Version verschoben. Das Überspringen dieses Schritts kann zu langsam laufenden Abfragen führen.
  • Wenn Sie auf PostgreSQL Version 10 aktualisiert haben, führen Sie REINDEX für alle Hash-Indizes aus, die Sie haben. Hash-Indizes wurden in Version 10 geändert und müssen neu erstellt werden. Um ungültige Hash-Indizes zu finden, führen Sie diese SQL für jede Datenbank aus, die Hash-Indizes enthält:
SELECT idx.indrelid::regclass AS table_name, 
   idx.indexrelid::regclass AS index_name 
FROM pg_catalog.pg_index idx
   JOIN pg_catalog.pg_class cls ON cls.oid = idx.indexrelid 
   JOIN pg_catalog.pg_am am ON am.oid = cls.relam 
WHERE am.amname = 'hash' 
AND NOT idx.indisvalid;

War dieser Artikel hilfreich?


Benötigen Sie Hilfe zur Fakturierung oder technischen Support?