Aktualisieren einer PostgreSQL-DB-Engine für Aurora PostgreSQL - Amazon Aurora

Aktualisieren einer PostgreSQL-DB-Engine für Aurora PostgreSQL

Amazon Aurora stellt neue Versionen des PostgreSQL-Datenbankmoduls AWS-Regionen erst nach umfangreichen Tests zur Verfügung. Sie können Ihre Aurora-PostgreSQL-DB-Cluster auf die neue Version aktualisieren, wenn diese in Ihrer Region verfügbar ist.

Abhängig von der Version von Aurora PostgreSQL, die Ihr DB-Cluster derzeit ausführt, ist ein Upgrade auf die neue Version entweder ein Nebenversions- oder ein Hauptversions-Upgrade. Zum Beispiel ist das Upgrade eines DB-Clusters von Aurora PostgreSQL 11.15 auf Aurora PostgreSQL 13.6 ein Hauptversions-Upgrade. Das Upgrade eines DB-Clusters von Aurora PostgreSQL 13.3 auf Aurora PostgreSQL 13.7 hingegen ist ein Nebenversions-Upgrade. In den folgenden Themen finden Sie Informationen darüber, wie beide Arten von Upgrades durchgeführt werden.

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

Zwischen Haupt- und Nebenversions-Upgrades gibt es folgende Unterschiede:

Nebenversions-Upgrades und -Patches

Nebenversions-Upgrades und -Patches enthalten nur Änderungen, die mit bestehenden Anwendungen abwärtskompatibel sind. Nebenversions-Upgrades und -Patches stehen Ihnen erst zur Verfügung, nachdem Aurora PostgreSQL sie getestet und genehmigt hat.

Nebenversions-Upgrades können von Aurora automatisch angewendet werden. Wenn Sie einen neuen Aurora-PostgreSQL-DB-Cluster erstellen, ist die Option Enable minor version upgrade (Nebenversions-Upgrade aktivieren) vorausgewählt. Wenn Sie diese Option nicht deaktivieren, werden Upgrades von Nebenversionen während des geplanten Wartungsfensters automatisch angewendet. Weitere Informationen zur Option für das automatische Nebenversions-Upgrade (AMVU) und wie Sie Ihren Aurora-DB-Cluster ändern, um ihn zu verwenden, finden Sie unter Automatische Nebenversions-Upgrades für Aurora-DB-Cluster .

Wenn die Option für das automatische Upgrade der Nebenversion für Ihren Aurora-PostgreSQL-DB-Cluster nicht festgelegt ist, wird Aurora PostgreSQL nicht automatisch auf die neue Nebenversion aktualisiert. Stattdessen werden Sie von Aurora zum Upgrade aufgefordert, wenn eine neue Nebenversion in IhrerAWS-Region veröffentlicht wird und Ihr DB-Cluster von Aurora PostgreSQL eine ältere Nebenversion ausführt. Dazu wird den Wartungsaufgaben für Ihren Cluster eine Empfehlung hinzugefügt.

Patches gelten nicht als Upgrade und werden nicht automatisch angewendet. Aurora PostgreSQL fordert Sie auf, alle Patches anzuwenden, indem es den Wartungsaufgaben für Ihren Aurora-PostgreSQL-DB-Cluster eine Empfehlung hinzufügt. Weitere Informationen finden Sie unter So führen Sie Upgrades von Nebenversionen durch und wenden Patches an.

Anmerkung

Patches, die Sicherheits- oder andere kritische Probleme lösen, werden ebenfalls als Wartungsaufgaben hinzugefügt. Diese Patches sind jedoch erforderlich. Stellen Sie sicher, dass Sie Sicherheitspatches auf Ihren Aurora-PostgreSQL-DB-Cluster anwenden, wenn diese in Ihren ausstehenden Wartungsaufgaben verfügbar sind.

Beim Upgrade-Prozess kann es zu kurzen Ausfällen kommen, während jede Instance im Cluster auf die neue Version aktualisiert wird. Nach den Aurora-PostgreSQL-Versionen 14.3.3, 13.7.3, 12.11.3, 11.16.3, 10.21.3 und anderen höheren Versionen dieser Nebenversionen verwendet der Upgrade-Prozess jedoch die Zero Downtime Patching (ZDP)-Funktion. Diese Funktion minimiert Ausfälle und eliminiert sie in den meisten Fällen vollständig. Weitere Informationen finden Sie unter Nebenversions-Upgrades und Zero-Downtime-Patching.

Anmerkung

ZDP wird nicht für Aurora PostgreSQL DB-Cluster unterstützt, die als Aurora Serverless v2, Aurora Serverless v1, Aurora globale Datenbanken oder Babelfish konfiguriert sind.

Hauptversions-Upgrades

Im Gegensatz zu Upgrades und Patches für Nebenversionen verfügt Aurora PostgreSQL über keine automatische Upgrade-Option für Hauptversionen. Hauptversions-Upgrades können Datenbankänderungen enthalten, die mit vorhandenen Anwendungen nicht abwärtskompatibel sind. Neue Funktionalität kann dazu führen, dass Ihre vorhandenen Anwendungen nicht mehr ordnungsgemäß funktionieren.

Zur Vermeidung von Problemen empfehlen wir dringend, dem in Vor dem Upgrade Ihres Produktions-DB-Clusters auf eine neue Hauptversion beschriebenen Verfahren zu folgen, bevor Sie die DB-Instances in Ihren Aurora-PostgreSQL-DB-Clustern upgraden. Stellen Sie zunächst sicher, dass Ihre Anwendungen mit der neuen Version ausgeführt werden können, indem Sie diesem Verfahren folgen. Dann können Sie Ihren Aurora-PostgreSQL-DB-Cluster manuell auf die neue Version aktualisieren.

Beim Upgrade-Prozess kann es zu kurzen Ausfällen kommen, während jede Instance im Cluster auf die neue Version aktualisiert wird. Der vorläufige Planungsprozess braucht ebenfalls Zeit. Wir empfehlen Ihnen, Upgrade-Aufgaben immer während des Wartungsfensters Ihres Clusters oder bei minimalem Betrieb auszuführen. Weitere Informationen finden Sie unter Durchführen eines Hauptversions-Upgrades.

Anmerkung

Sowohl Upgrades von Neben- als auch von Hauptversionen können kurze Ausfälle verursachen. Aus diesem Grund empfehlen wir dringend, dass Sie Upgrades während Ihres Wartungsfensters oder in anderen Zeiträumen geringer Auslastung durchführen oder planen.

Durchführen eines Hauptversions-Upgrades

Hauptversions-Upgrades können Datenbankänderungen enthalten, die möglicherweise nicht mit früheren Versionen der Datenbank abwärtskompatibel sind. Neue Funktionalität einer neuen Version kann dazu führen, dass Ihre vorhandenen Anwendungen nicht mehr ordnungsgemäß funktionieren. Zur Vermeidung von Problemen wendet Amazon Aurora Hauptversions-Upgrades nicht automatisch an. Wir empfehlen vielmehr, dass Sie ein Hauptversions-Upgrade sorgfältig planen, indem Sie die folgenden Schritte ausführen:

  1. Wählen Sie die gewünschte Hauptversion aus der Liste der verfügbaren Ziele aus, die für Ihre Version in der Tabelle aufgeführt sind. Sie können eine genaue Liste der Versionen abrufen, die in Ihrer AWS-Region für Ihre aktuelle Version verfügbar sind, indem Sie die AWS CLI verwenden. Details hierzu finden Sie unter Abrufen einer Liste von verfügbaren Versionen in Ihrer AWS-Region.

  2. Stellen Sie sicher, dass Ihre Anwendungen bei einer Testbereitstellung der neuen Version erwartungsgemäß funktionieren. Weitere Informationen zum vollständigen Prozess finden Sie unter Vor dem Upgrade Ihres Produktions-DB-Clusters auf eine neue Hauptversion.

  3. Nachdem Sie überprüft haben, dass Ihre Anwendungen bei der Testbereitstellung wie erwartet funktionieren, können Sie Ihren Cluster aktualisieren. Details hierzu finden Sie unter Upgrade der Aurora-PostgreSQL-Engine auf eine neue Hauptversion.

Anmerkung

Derzeit können Sie einen Aurora-PostgreSQL-DB-Cluster, auf dem Babelfish ausgeführt wird, nicht auf eine neue Hauptversion aktualisieren.

In der Tabelle finden Sie die Hauptversions-Upgrades, die für verschiedene Aurora-PostgreSQL-DB-Versionen verfügbar sind.

Überprüfen Sie für jede Version, die Sie in Betracht ziehen, immer die Verfügbarkeit der DB-Instance-Klasse Ihres Clusters. Weitere Informationen zu DB-Instance-Klassen, einschließlich der Frage, welche Graviton2-basiert und welche Intel-basiert sind, finden Sie unter Aurora DB-Instance-Klassen.

Abrufen einer Liste von verfügbaren Versionen in Ihrer AWS-Region

Sie können eine Liste der Engine-Versionen abrufen, die als Upgrade-Ziele für Ihre Aurora-PostgreSQL-DB verfügbar sind, indem Sie Ihre AWS-Region mit dem folgenden AWS CLI-Befehl describe-db-engine-versions wie folgt abfragen.

Für Linux, macOS oder Unix:

aws rds describe-db-engine-versions \ --engine aurora-postgresql \ --engine-version 12.10 \ --query 'DBEngineVersions[].ValidUpgradeTarget[?IsMajorVersionUpgrade == `true`].{EngineVersion:EngineVersion}' \ --output text

Für Windows:

aws rds describe-db-engine-versions ^ --engine aurora-postgresql ^ --engine-version 12.10 ^ --query "DBEngineVersions[].ValidUpgradeTarget[?IsMajorVersionUpgrade == `true`].{EngineVersion:EngineVersion}" ^ --output text

In einigen Fällen ist die Version, auf die Sie upgraden möchten, kein Ziel für Ihre aktuelle Version. Verwenden Sie in solchen Fällen die Informationen in versions table, um Nebenversions-Upgrades durchzuführen, bis sich Ihr Cluster in einer Version befindet, die Ihr ausgewähltes Ziel in seiner Zielzeile enthält.

Vor dem Upgrade Ihres Produktions-DB-Clusters auf eine neue Hauptversion

Jede neue Hauptversion enthält Verbesserungen am Abfrageoptimierer, die auf Leistungssteigerung ausgelegt sind. Ihr Workload kann jedoch Abfragen enthalten, die in der neuen Version zu einem Plan mit schlechter Leistung führen. Aus diesem Grund empfehlen wir Ihnen, die Leistung zu testen und zu überprüfen, bevor Sie ein Upgrade in der Produktion durchführen. Sie können die Stabilität des Abfrageplans über Versionen hinweg verwalten, indem Sie die Erweiterung Query Plan Management (QPM) verwenden, wie in Sicherstellen der Planstabilität nach einem größeren Versions-Upgrade ausführlich beschrieben.

Bevor Sie Ihre Produktions-DB-Cluster von Aurora PostgreSQL auf eine neue Hauptversion upgraden, wird dringend empfohlen, das Upgrade zu testen, um sicherzustellen, dass alle Ihre Anwendungen ordnungsgemäß funktionieren:

  1. Halten Sie eine versionskompatible Parametergruppe bereit.

    Wenn Sie eine benutzerdefinierte DB-Instance- oder DB-Cluster-Parametergruppe verwenden, haben Sie zwei Möglichkeiten:

    1. Geben Sie die Standard-DB-Instance, die DB-Cluster-Parametergruppe oder beides für die neue DB-Engine-Version an.

    2. Erstellen Sie eine eigene benutzerdefinierte Parametergruppe für die neue DB-Engine-Version.

    Wenn Sie eine neue DB-Instance- oder eine neue DB-Cluster-Parametergruppe als Teil der Upgrade-Anforderung zuordnen, stellen Sie sicher, dass Sie die Datenbank nach Abschluss des Upgrades neu starten, um die Parameter anzuwenden. Wenn eine DB-Instance neu gestartet werden muss, um die Änderungen der Parametergruppe zu übernehmen, wird als Parametergruppenstatus der Instance angegebe pending-reboot. Sie können den Parametergruppenstatus einer Instance in der Konsole anzeigen oder einen CLI-Befehl, wie z. B. describe-db-instances oder describe-db-clusters, verwenden.

  2. Auf nicht unterstützte Verwendung prüfen:

    • Übernehmen Sie oder machen Sie alle offenen vorbereiteten Transaktionen rückgängig, bevor Sie ein Upgrade durchführen. Mit der folgenden Abfrage können Sie sicherstellen, dass für Ihre Instance keine geöffneten vorbereiteten Transaktionen vorhanden sind.

      SELECT count(*) FROM pg_catalog.pg_prepared_xacts;
    • Entfernen Sie alle Anwendungen der reg*-Datentypen, bevor Sie versuchen, einen Upgrade durchzuführen. Bis auf regtype und regclass ist kein Upgrade der reg*-Datentypen möglich. Das Dienstprogramm pg_upgrade (das von Amazon Aurora zur Durchführung des Upgrades verwendet wird) kann diesen Datentyp nicht beibehalten. Weitere Informationen zu diesem Dienstprogramm finden Sie unter pg_upgrade in der PostgreSQL-Dokumentation.

      Um zu überprüfen, dass keine Anwendungen der nicht unterstützten reg*-Datentypen vorhanden sind, geben Sie für jede Datenbank die folgende Abfrage aus.

      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');
    • Wenn Sie ein Upgrade eines DB-Clusters mit Aurora PostgreSQL Version 10.18 oder höher durchführen, für den die Erweiterung pgRouting installiert ist, entfernen Sie diese Erweiterung, bevor Sie auf Version 12.4 oder höher aktualisieren.

  3. Entfernen von logischen Replikations-Slots.

    Der Upgrade-Vorgang kann nicht fortgesetzt werden, wenn der Aurora PostgreSQL DB-Cluster logische Replikations-Slots verwendet. Logische Replikations-Slots werden in der Regel für kurzfristige Datenmigrationsaufgaben verwendet, z. B. für die Migration von Daten mit AWS DMS oder für die Replikation von Tabellen aus der Datenbank in Data Lakes, BI-Tools oder andere Ziele. Vergewissern Sie sich vor dem Upgrade, dass Sie den Zweck der vorhandenen logischen Replikations-Slots kennen, und bestätigen Sie, dass sie gelöscht werden dürfen. Sie können mit der folgenden Abfrage nach logischen Replikationssteckplätzen suchen:

    SELECT * FROM pg_replication_slots;

    Wenn die logischen Replikations-Slots noch verwendet werden, sollten Sie sie nicht löschen, und Sie können mit dem Upgrade nicht fortfahren. Wenn die logischen Replikations-Slots jedoch nicht benötigt werden, können Sie sie mit folgendem SQL-Befehl löschen:

    SELECT pg_drop_replication_slot(slot_name);
  4. Führen Sie ein Backup durch.

    Der Aktualisierungsprozess erstellt während des Upgrades einen DB-Cluster-Snapshot des DB-Clusters. Wenn Sie vor dem Upgrade auch ein manuelles Backup durchführen möchten, finden Sie weitere Informationen unter Erstellen eines DB-Cluster-Snapshots.

  5. Aktualisieren Sie bestimmte Erweiterungen auf die neueste verfügbare Version, bevor Sie das Upgrade der Hauptversion durchführen. Zu den Erweiterungen, die aktualisiert werden sollen, gehören folgende:

    • pgRouting

    • postgis_raster

    • postgis_tiger_geocoder

    • postgis_topology

    • address_standardizer

    • address_standardizer_data_us

    Führen Sie den folgenden Befehl für jede derzeit installierte Erweiterung aus.

    ALTER EXTENSION PostgreSQL-extension UPDATE TO 'new-version'

    Weitere Informationen finden Sie unter Aktualisieren von PostgreSQL-Erweiterungen. Weitere Informationen zum Aktualisieren von PostGIS finden Sie unterSchritt 6: Upgrade der PostGIS-Erweiterung.

  6. Wenn Sie ein Upgrade auf Version 11.x durchführen, löschen Sie die Erweiterungen, die nicht unterstützt werden, bevor Sie das Upgrade der Hauptversion durchführen. Die zu löschenden Erweiterungen umfassen:

    • chkpass

    • tsearch2

  7. Löschen Sie unknown-Datentypen, abhängig von Ihrer Zielversion.

    PostgreSQL-Version 10 unterstützt den Datentyp unknown nicht. Wenn eine Datenbank der Version 9.6 den Datentyp unknown verwendet, wird bei einem Upgrade auf Version 10 eine Fehlermeldung wie die folgende angezeigt.

    Database instance is in a state that cannot be upgraded: PreUpgrade checks failed: 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."

    Verwenden Sie den folgenden SQL-Code für jede Datenbank, um den unknown-Datentyp in Ihrer Datenbank zu finden, damit Sie solche Spalten entfernen oder in unterstützte Datentypen ändern können.

    SELECT n.nspname, c.relname, a.attname 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 = 'pg_catalog.unknown'::pg_catalog.regtype AND c.relkind IN ('r','m','c') AND c.relnamespace = n.oid AND n.nspname !~ '^pg_temp_' AND n.nspname !~ '^pg_toast_temp_' AND n.nspname NOT IN ('pg_catalog', 'information_schema');
  8. Führen Sie ein Test-Upgrade durch.

    Es wird dringend empfohlen, das Upgrade der Hauptversion auf einem Duplikat Ihrer Produktionsdatenbank zu testen, bevor Sie versuchen, das Upgrade für Ihre Produktionsdatenbank auszuführen. Um ein Duplikat der Test-Instance zu erstellen, können Sie Ihre Datenbank entweder aus einem aktuellen Snapshot wiederherstellen oder Ihre Datenbank klonen. Weitere Informationen finden Sie unter Wiederherstellung aus einem Snapshot oder Klonen eines Volumes für einen Amazon-Aurora-DB-Cluster.

    Weitere Informationen finden Sie unter Upgrade der Aurora-PostgreSQL-Engine auf eine neue Hauptversion.

  9. Aktualisieren Sie Ihre Produktionsinstance.

    Wenn das Hauptversions-Upgrade für den Testlauf erfolgreich ist, sollten Sie jetzt in der Lage sein, Ihre Produktionsdatenbank sicher zu aktualisieren. Weitere Informationen finden Sie unter Upgrade der Aurora-PostgreSQL-Engine auf eine neue Hauptversion.

    Anmerkung

    Während des Upgrade-Prozesses erstellt Aurora PostgreSQL einen DB-Cluster-Snapshot, wenn die Backup-Aufbewahrungszeit des Clusters größer als 0 ist. Sie können während dieses Prozesses keine punktuelle Wiederherstellung Ihres Clusters durchführen. Sie können später eine Wiederherstellung nach dem Zeitpunkt vor dem Beginn des Upgrades und nach Abschluss des automatischen Snapshots Ihrer Instance durchführen. Sie können eine Point-in-Time-Wiederherstellung auf eine frühere Nebenversion jedoch nicht durchführen.

    Für Informationen zu einem laufenden Upgrade können Sie mit Amazon RDS zwei Protokolle anzeigen, die von dem pg_upgrade-Dienstprogramm erstellt werden. Diese sind pg_upgrade_internal.log und pg_upgrade_server.log. Amazon Aurora hängt einen Zeitstempel an den Dateinamen für diese Protokolle an. Sie können diese Protokolle wie jedes andere Protokoll einsehen. Weitere Informationen finden Sie unter Überwachen von Amazon Aurora-Protokolldateien.

  10. Aktualisieren Sie PostgreSQL-Erweiterungen. Bei einem PostgreSQL-Upgrade-Prozess werden keine PostgreSQL-Erweiterungen aktualisiert. Weitere Informationen finden Sie unter Aktualisieren von PostgreSQL-Erweiterungen.

Nachdem Sie ein Upgrade der Hauptversion abgeschlossen haben, empfehlen wir Folgendes:

  • Führen Sie die ANALYZE-Operation aus, um die Tabelle pg_statistic zu aktualisieren.

  • Wenn Sie auf PostgreSQL Version 10 aktualisiert haben, führen Sie REINDEX auf allen Hash-Indizes aus, die Sie besitzen. Hash-Indizes wurden in Version 10 geändert und müssen neu erstellt werden. Um ungültige Hash-Indizes zu finden, führen Sie die folgende SQL-Anweisung 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;
  • Wir empfehlen, dass Sie Ihre Anwendung auf der aktualisierten Datenbank mit ähnlicher Workload testen, um sicherzustellen, dass alles wie erwartet funktioniert. Nachdem das Upgrade bestätigt wurde, können Sie diese Testinstance löschen.

Upgrade der Aurora-PostgreSQL-Engine auf eine neue Hauptversion

Wenn Sie den Upgrade-Prozess auf eine neue Hauptversion einleiten, erstellt Aurora PostgreSQL einen Snapshot des Aurora-DB-Clusters, bevor er Änderungen an Ihrem Cluster vornimmt. Dieser Snapshot wird nur für Hauptversions-Upgrades erstellt, nicht für Nebenversions-Upgrades. Wenn der Upgrade-Vorgang abgeschlossen ist, finden Sie diesen Snapshot unter den manuellen Snapshots, die unter Snapshots in der RDS-Konsole aufgeführt sind. Der Snapshot-Name enthält preupgrade als Präfix, den Namen Ihres Aurora-PostgreSQL-DB-Clusters, die Quellversion, die Zielversion sowie das Datum und den Zeitstempel, wie im folgenden Beispiel gezeigt.

preupgrade-docs-lab-apg-global-db-12-8-to-13-6-2022-05-19-00-19

Nach Abschluss des Upgrades können Sie den Snapshot, den Aurora erstellt und in Ihrer manuellen Snapshot-Liste erstellt und gespeichert hat, verwenden, um den DB-Cluster gegebenenfalls auf seine vorherige Version wiederherzustellen.

Tipp

Im Allgemeinen bieten Snapshots viele Möglichkeiten, Ihren Aurora-DB-Cluster zu verschiedenen Zeitpunkten wiederherzustellen. Weitere Informationen hierzu finden Sie unter Wiederherstellen aus einem DB-Cluster-Snapshot und Wiederherstellen eines DB-Clusters zu einer bestimmten Zeit. Aurora PostgreSQL unterstützt jedoch nicht die Verwendung eines Snapshots für die Wiederherstellung auf eine frühere Nebenversion.

Während des Hauptversions-Upgrades weist Aurora ein Volume zu und klont den Quell-DB-Cluster von Aurora PostgreSQL. Wenn das Upgrade aus irgendeinem Grund fehlschlägt, verwendet Aurora PostgreSQL den Klon, um das Upgrade zurückzusetzen. Nachdem mehr als 15 Klone eines Quell-Volumes zugewiesen wurden, werden nachfolgende Klone zu vollständigen Kopien und dauern länger. Dies kann dazu führen, dass der Upgrade-Prozess ebenfalls länger dauert. Wenn Aurora PostgreSQL das Upgrade zurücksetzt, beachten Sie Folgendes:

  • Möglicherweise sehen Sie Fakturierungseinträge und Metriken sowohl für das ursprüngliche Volume als auch für das geklonte Volume, das während des Upgrades zugewiesen wurde. Aurora PostgreSQL bereinigt das zusätzliche Volume, nachdem das Aufbewahrungsfenster für Cluster-Backups den Zeitpunkt des Upgrades überschritten hat.

  • Die nächste regionsübergreifende Snapshot-Kopie aus diesem Cluster ist eine vollständige Kopie anstelle einer inkrementellen Kopie.

Um die DB-Instances, aus denen Ihr Cluster besteht, sicher zu aktualisieren, verwendet Aurora PostgreSQL das Dienstprogramm pg_upgrade. Nach Abschluss des Writer-Upgrades kommt es zu einem kurzen Ausfall aller Reader-Instances, während sie auf die neue Hauptversion aktualisiert werden. Weitere Informationen zu diesem PostgreSQL-Dienstprogramm finden Sie unter pg_upgrade in der PostgreSQL-Dokumentation.

Sie können Ihren Aurora-PostgreSQL-DB-Cluster auf eine neue Version upgraden, indem Sie die AWS Management Console, die AWS CLI oder die RDS-API verwenden.

So führen Sie ein Upgrade der Engine-Version eines DB-Clusters durch
  1. Melden Sie sich bei der AWS Management Console an und öffnen Sie die Amazon-RDS-Konsole unter https://console.aws.amazon.com/rds/.

  2. Wählen Sie im Navigationsbereich Databases (Datenbanken) und dann den DB-Cluster aus, den Sie upgraden möchten.

  3. Wählen Sie Modify aus. Die Seite Modify DB cluster (DB-Cluster ändern) wird angezeigt.

  4. Wählen Sie für Motorversion die neue Version.

  5. Klicken Sie auf Weiter und überprüfen Sie die Zusammenfassung aller Änderungen.

  6. Wählen Sie Apply immediately, um die Änderungen sofort anzuwenden. Die Auswahl dieser Option kann in einigen Fällen einen Ausfall verursachen. Weitere Informationen finden Sie unter Ändern eines Amazon Aurora-DB-Clusters.

  7. Überprüfen Sie auf der Bestätigungsseite Ihre Änderungen. Wenn sie korrekt sind, wählen Sie Modify Cluster (Cluster ändern) aus, um Ihre Änderungen zu speichern.

    Oder klicken Sie auf Zurück, um Ihre Änderungen zu bearbeiten, oder auf Abbrechen, um Ihre Änderungen zu verwerfen.

Mit dem AWS CLI-Befehl modify-db-cluster können Sie die Engine-Version eines DB-Clusters upgraden. Geben Sie die folgenden Parameter an:

  • --db-cluster-identifier – der Name des DB-Clusters.

  • --engine-version – die Versionsnummer der Datenbank-Engine, auf die das Upgrade durchgeführt wird Verwenden Sie den AWS CLI-Befehl describe-db-engine-versions, um weitere Informationen über gültige Engine-Versionen zu erhalten.

  • --allow-major-version-upgrade – ein erforderliches Flag, wenn die Hauptversion des --engine-version-Parameters von der aktuellen Hauptversion des DB-Clusters abweicht

  • --no-apply-immediately – Änderungen im nächsten Wartungszeitraum anwenden Verwenden Sie , um Änderungen sofort anzuwende --apply-immediately.

Beispiel

Für Linux, macOS oder Unix:

aws rds modify-db-cluster \ --db-cluster-identifier mydbcluster \ --engine-version new_version \ --allow-major-version-upgrade \ --no-apply-immediately

Für Windows:

aws rds modify-db-cluster ^ --db-cluster-identifier mydbcluster ^ --engine-version new_version ^ --allow-major-version-upgrade ^ --no-apply-immediately

Sie können die Engine-Version eines DB-Clusters upgraden, indem Sie die Operation ModifyDBCluster aufrufen. Geben Sie die folgenden Parameter an:

  • DBClusterIdentifier – der Name des DB-Clusters, z. B mydbcluster

  • EngineVersion – die Versionsnummer der Datenbank-Engine, auf die das Upgrade durchgeführt wird Über die Operation DescribeDBEngineVersions erhalten Sie Informationen über gültige Engine-Versionen.

  • AllowMajorVersionUpgrade – ein erforderliches Flag, wenn die Hauptversion des EngineVersion-Parameters von der aktuellen Hauptversion des DB-Clusters abweicht

  • ApplyImmediately – Änderungen sofort oder während des nächsten Wartungszeitraums anwenden Legen Sie den Wert auf fest, um Änderungen sofort anzuwende true. Legen Sie den Wert auf fest, um Änderungen im nächsten Wartungszeitraum durchzuführe false.

Hauptversions-Upgrades für globale Datenbanken

Bei einem globalen Aurora-Datenbank-Cluster aktualisiert der Upgrade-Prozess alle DB-Cluster, aus denen Ihre globale Aurora-Datenbank besteht, gleichzeitig. Damit wird sichergestellt, dass jeder dieselbe Aurora-PostgreSQL-Version ausführt. Außerdem wird sichergestellt, dass Änderungen an Systemtabellen, Datendateiformaten usw. automatisch auf alle sekundären Cluster repliziert werden.

Wenn Sie einen globalen Datenbank-Cluster auf eine neue Hauptversion von Aurora PostgreSQL aktualisieren möchten, empfehlen wir Ihnen, Ihre Anwendungen auf der aktualisierten Version zu testen, wie in Vor dem Upgrade Ihres Produktions-DB-Clusters auf eine neue Hauptversion ausführlich beschrieben. Bereiten Sie Ihre DB-Cluster-Parametergruppe und die DB-Parametergruppeneinstellungen für jede AWS-Region in Ihrer globalen Aurora-Datenbank vor dem Upgrade wie in step 1. von Vor dem Upgrade Ihres Produktions-DB-Clusters auf eine neue Hauptversion beschrieben vor.

Wenn für den Aurora-PostgreSQL-Datenbank-Cluster ein Recovery Point Objective (RPO) für den Parameter rds.global_db_rpo festgelegt ist, müssen Sie den Parameter zurücksetzen, bevor Sie das Upgrade durchführen. Der Hauptversions-Upgrade-Prozess funktioniert nicht, wenn das RPO aktiviert ist. Dieser Parameter ist standardmäßig deaktiviert. Weitere Informationen über globale Aurora-PostgreSQL-Datenbanken und RPO finden Sie unter Verwalten von RPOs für Aurora PostgreSQL–basierte globale Datenbanken.

Nachdem Sie überprüft haben, dass Ihre Anwendungen bei der Testbereitstellung der neuen Version erwartungsgemäß ausgeführt werden, können Sie den Upgrade-Prozess starten. Lesen Sie dazu den Abschnitt Upgrade der Aurora-PostgreSQL-Engine auf eine neue Hauptversion. Wählen Sie unbedingt das Element Global database (Globale Datenbank) auf der obersten Ebene der Liste Databases (Datenbanken) in der RDS-Konsole aus, wie in der folgenden Abbildung dargestellt.


                    Ein Konsolenbild mit einer globalen Aurora-Datenbank, einem DB-Cluster von Aurora Serverless und einem weiteren Aurora-PostgreSQL-DB-Cluster

Wie bei jeder Änderung können Sie bestätigen, dass der Prozess fortgesetzt werden soll, wenn Sie dazu aufgefordert werden.


                    Das Konsolenbild zeigt die Aufforderung zur Bestätigung des Upgrade-Prozesses für einen Aurora-PostgreSQL-DB-Cluster

Anstatt die Konsole zu verwenden, können Sie den Upgrade-Vorgang mit der AWS CLI oder der RDS-API starten. Wie bei der Konsole arbeiten Sie wie folgt auf dem globalen Aurora-Datenbankcluster und nicht auf einem seiner Bestandteile:

  • Verwenden Sie den AWS CLI-Befehl modify-global-Cluster, um das Upgrade für Ihre globale Aurora--Datenbank mit der AWS CLI zu starten.

  • Verwenden Sie die ModifyGlobalCluster-API zum Starten des Upgrades.

So führen Sie Upgrades von Nebenversionen durch und wenden Patches an

Nebenversions-Upgrades und Patches werden in AWS-Regionen erst nach umfangreichen Tests zur Verfügung gestellt. Vor der Veröffentlichung von Upgrades und Patches testet Aurora PostgreSQL, um sicherzustellen, dass bekannte Sicherheitsprobleme, Fehler und andere Probleme, die nach der Veröffentlichung der Community-Nebenversion auftreten, die allgemeine Stabilität der Aurora PostgreSQL-Flotte nicht beeinträchtigen.

Sobald Aurora PostgreSQL neue Nebenversionen zur Verfügung stellt, können die Instances, aus denen Ihr Aurora-PostgreSQL-DB-Cluster besteht, während des angegebenen Wartungsfensters automatisch aktualisiert werden. Dazu muss für Ihren Aurora-PostgreSQL-DB-Cluster die Option Enable auto minor version upgrade (Automatische Aktualisierung von Nebenversionen aktivieren) ausgewählt sein. Für alle DB-Instances, aus denen Ihr Aurora-PostgreSQL-DB-Cluster besteht, muss die Option für das automatische Nebenversions-Upgrade (AMVU) aktiviert sein, damit das Nebenversions-Upgrade im gesamten Cluster angewendet werden kann.

Tipp

Stellen Sie sicher, dass die Option Enable auto minor version upgrade (Automatische Aktualisierung von Nebenversionen aktivieren) für alle PostgreSQL-DB-Instances ausgewählt ist, aus denen Ihr Aurora-PostgreSQL-DB-Cluster besteht. Diese Option muss aktiviert sein, damit jede Instance im DB-Cluster funktioniert.

Sie können den Wert der Option Enable auto minor version upgrade (Automatische Aktualisierung von Nebenversionen aktivieren) für alle Ihre Aurora-PostgreSQL-DB-Cluster überprüfen, indem Sie den AWS CLI-Befehl describe-db-instances mit der folgenden Abfrage verwenden.

aws rds describe-db-instances \ --query '*[].{DBClusterIdentifier:DBClusterIdentifier,DBInstanceIdentifier:DBInstanceIdentifier,AutoMinorVersionUpgrade:AutoMinorVersionUpgrade}'

Diese Abfrage gibt eine Liste aller Aurora-DB-Cluster und ihrer Instances mit dem Wert true oder false für den Status der Einstellung AutoMinorVersionUpgrade zurück. Der dargestellte Befehl geht davon aus, dass Sie Ihre AWS CLI mit Ihrer Standard-AWS-Region als Ziel konfiguriert haben.

Weitere Informationen zur AMVU-Option und wie Sie Ihren Aurora-DB-Cluster ändern, um diese zu verwenden, finden Sie unter Automatische Nebenversions-Upgrades für Aurora-DB-Cluster .

Sie können Ihren Aurora-PostgreSQL-DB-Cluster auf neue Nebenversionen aktualisieren, indem Sie entweder auf Wartungsaufgaben reagieren oder den Cluster so ändern, dass er die neue Version verwendet.

Sie können alle verfügbaren Upgrades oder Patches für Ihre Aurora-PostgreSQL-DB-Cluster identifizieren, indem Sie die RDS-Konsole verwenden und das Menü Recommendations (Empfehlungen) öffnen. Dort finden Sie eine Liste verschiedener Wartungsprobleme wie Old minor versions (Alte Nebenversionen) aus. Abhängig von Ihrer Produktionsumgebung können Sie mit Schedule (Planen) das Upgrade planen oder mit Apply now (Jetzt anwenden) sofort Maßnahmen ergreifen, wie im Folgenden gezeigt.


                Das Konsolenabbild zeigt eine Empfehlung zum Upgrade auf eine neuere Nebenversion.

Weitere Informationen zum Verwalten eines Aurora-DB-Clusters, einschließlich der manuellen Anwendung von Patches und Nebenversions-Upgrades, finden Sie unter Warten eines Amazon Aurora-DB-Clusters.

Nebenversions-Upgrades und Zero-Downtime-Patching

Beim Upgrade eines AuroraPostgreSQL-DB-Clusters kann es zu einem Ausfall kommen. Beim Upgrade-Prozess wird die Datenbank heruntergefahren, während sie aktualisiert wird. Wenn Sie das Upgrade starten, während die Datenbank ausgelastet ist, verlieren Sie alle Verbindungen und Transaktionen, die der DB-Cluster verarbeitet. Wenn Sie warten, bis die Datenbank im Leerlauf ist, um das Upgrade durchzuführen, müssen Sie möglicherweise lange warten.

Die Funktion „Null-Downtime Patching“ (ZDP, Patchen ohne Ausfallzeiten) verbessert den Upgrade-Prozess. Mit dem ZDP können sowohl Upgrades als auch Patches mit minimalen Auswirkungen auf Ihren Aurora-PostgreSQL-DB-Cluster angewendet werden. ZDP wird verwendet, wenn Patches oder neuere Upgrades von Nebenversionen auf Aurora-PostgreSQL-Versionen 14.3.3, 13.7.3, 12.11.3, 11.16.3, 10.21.3 und anderen höheren Versionen dieser Nebenversionen und neueren Hauptversionen angewendet werden. Das heißt, bei einem Upgrade auf neue Nebenversionen nach einer dieser Versionen wird ZDP verwendet.

Anmerkung

ZDP wird für Aurora-PostgreSQL-DB-Cluster, die konfiguriert sind als Aurora Serverless v2,Aurora Serverless v1, Aurora Global Databases oder Babelfish.

ZDP arbeitet, indem es die aktuellen Client-Verbindungen zu Ihrem Aurora PostgreSQL DB-Cluster während des Aurora PostgreSQL-Upgrade-Prozesses beibehält. Wenn das ZDP erfolgreich abgeschlossen wird, werden Anwendungssitzungen beibehalten und die Datenbank-Engine wird während des laufenden Upgrades neu gestartet. Der Neustart der Datenbank-Engine kann zwar zu einem Abfall des Durchsatzes führen, dieser dauert jedoch normalerweise nur wenige Sekunden oder maximal etwa 1 Minute.

In einigen Fällen ist das Zero-Downtime-Patching (ZDP) möglicherweise nicht erfolgreich. Wenn beispielsweise lang andauernde Abfragen oder Transaktionen ausgeführt werden, muss das ZDP diese möglicherweise abbrechen, um den Vorgang abzuschließen. Wenn Anweisungen für Datendefinitionssprache (DDL) ausgeführt werden oder temporäre Tabellen oder Tabellensperren aus einem anderen Grund verwendet werden, muss ZDP möglicherweise die offene Transaktion abbrechen. Parameteränderungen, die sich auf Ihrem Aurora-PostgreSQL-DB-Cluster oder dessen Instances im Status pending befinden, beeinträchtigen ebenfalls das ZDP.

Metriken und Ereignisse für ZDP-Operationen finden Sie auf der Seite Events (Ereignisse) in der Konsole. Zu den Ereignissen gehören der Start des ZDP-Upgrades und der Abschluss des Upgrades. In diesem Fall können Sie feststellen, wie lange der Prozess gedauert hat und wie viele Verbindungen während des Neustarts aufrecht erhalten und abgebrochen wurden. Details finden Sie in Ihrem Datenbank-Fehlerprotokoll.

Durchführen eines Upgrades der Aurora-PostgreSQL-Engine auf eine neue Nebenversion

Sie können Ihren Aurora-PostgreSQL-DB-Cluster auf eine neue Nebenversion aktualisieren, indem Sie die Konsole, die AWS CLI oder die RDS-API verwenden. Bevor Sie das Aktualisieren durchführen, wird das Befolgen der selben bewährten Methoden empfohlen, die für Upgrades der Hauptversion empfohlen wird. Wie bei neuen Hauptversionen können auch neue Nebenversionen Optimizer-Verbesserungen aufweisen, z. B. Korrekturen, die Regressionen des Abfrageplans verursachen können. Um die Stabilität des Plans zu gewährleisten, wird die Verwendung der Erweiterung Query Plan Management (QPM) empfohlen, wie inSicherstellen der Planstabilität nach einem größeren Versions-Upgrade.

So aktualisieren Sie die Engine-Version Ihres Aurora-PostgreSQL-DB-Clusters.
  1. Melden Sie sich bei der AWS Management Console an und öffnen Sie die Amazon-RDS-Konsole unter https://console.aws.amazon.com/rds/.

  2. Wählen Sie im Navigationsbereich Databases (Datenbanken) und dann den DB-Cluster aus, den Sie upgraden möchten.

  3. Wählen Sie Modify aus. Die Seite Modify DB cluster (DB-Cluster ändern) wird angezeigt.

  4. Wählen Sie für Motorversion die neue Version.

  5. Klicken Sie auf Weiter und überprüfen Sie die Zusammenfassung aller Änderungen.

  6. Wählen Sie Apply immediately, um die Änderungen sofort anzuwenden. Die Auswahl dieser Option kann in einigen Fällen einen Ausfall verursachen. Weitere Informationen finden Sie unter Ändern eines Amazon Aurora-DB-Clusters.

  7. Überprüfen Sie auf der Bestätigungsseite Ihre Änderungen. Wenn sie korrekt sind, wählen Sie Modify Cluster (Cluster ändern) aus, um Ihre Änderungen zu speichern.

    Oder klicken Sie auf Zurück, um Ihre Änderungen zu bearbeiten, oder auf Abbrechen, um Ihre Änderungen zu verwerfen.

Wenn Sie die Engine-Version eines DB-Clusters aktualisieren möchten, verwenden Sie den AWS CLI-Befehl modify-db-cluster mit den folgenden Parametern:

  • --db-cluster-identifier – Der Name Ihres Aurora-PostgreSQL-DB-Clusters.

  • --engine-version – die Versionsnummer der Datenbank-Engine, auf die das Upgrade durchgeführt wird Verwenden Sie den AWS CLI-Befehl describe-db-engine-versions, um weitere Informationen über gültige Engine-Versionen zu erhalten.

  • --no-apply-immediately – Änderungen im nächsten Wartungszeitraum anwenden Verwenden Sie --apply-immediately, um Änderungen sofort anzuwenden.

Für Linux, macOS oder Unix:

aws rds modify-db-cluster \ --db-cluster-identifier mydbcluster \ --engine-version new_version \ --no-apply-immediately

Für Windows:

aws rds modify-db-cluster ^ --db-cluster-identifier mydbcluster ^ --engine-version new_version ^ --no-apply-immediately

Sie können die Engine-Version eines DB-Clusters upgraden, indem Sie die Operation ModifyDBCluster aufrufen. Geben Sie die folgenden Parameter an:

  • DBClusterIdentifier – der Name des DB-Clusters, z. B mydbcluster

  • EngineVersion – die Versionsnummer der Datenbank-Engine, auf die das Upgrade durchgeführt wird Über die Operation DescribeDBEngineVersions erhalten Sie Informationen über gültige Engine-Versionen.

  • ApplyImmediately – Änderungen sofort oder während des nächsten Wartungszeitraums anwenden Legen Sie den Wert auf fest, um Änderungen sofort anzuwende true. Legen Sie den Wert auf fest, um Änderungen im nächsten Wartungszeitraum durchzuführe false.

Aktualisieren von PostgreSQL-Erweiterungen

Wenn Sie Ihren Aurora-PostgreSQL-DB-Cluster auf eine neue Hauptversion aktualisieren, werden die PostgreSQL-Erweiterungen nicht gleichzeitig aktualisiert. Bei den meisten Erweiterungen aktualisieren Sie die Erweiterung, nachdem das Upgrade der Hauptversion abgeschlossen ist. In einigen Fällen aktualisieren Sie die Erweiterung jedoch vor dem Upgrade der Aurora-PostgreSQL-DB-Engine. Weitere Informationen finden Sie unter list of extensions to update in Vor dem Upgrade Ihres Produktions-DB-Clusters auf eine neue Hauptversion.

Zum Installieren von PostgreSQL-Erweiterungen sind rds_superuser-Berechtigungen erforderlich. In der Regel delegiert ein rds_superuser Berechtigungen über bestimmte Erweiterungen an relevante Benutzer (Rollen), um die Verwaltung einer bestimmten Erweiterung zu erleichtern. Das heißt, dass die Aufgabe, alle Erweiterungen in Ihrem Aurora-PostgreSQL-DB-Cluster zu aktualisieren, viele verschiedene Benutzer (Rollen) betreffen kann. Beachten Sie dies, insbesondere wenn Sie den Upgrade-Prozess mithilfe von Skripten automatisieren möchten. Weitere Informationen über PostgreSQL-Berechtigungen und -Rollen finden Sie unter Sicherheit in Amazon Aurora PostgreSQL.

Anmerkung

Weitere Informationen zum Aktualisieren der PostGIS-Erweiterungsversion finden Sie unter Verwalten von Geodaten mit der PostGIS-Erweiterung (Schritt 6: Upgrade der PostGIS-Erweiterung).

Verwenden Sie zur Aktualisierung einer Erweiterung nach einem Upgrade der Engine den Befehl ALTER EXTENSION UPDATE.

ALTER EXTENSION extension_name UPDATE TO 'new_version';

Um Ihre derzeit installierten Erweiterungen aufzulisten, verwenden Sie den PostgreSQL-Katalog pg_extension in dem folgenden Befehl.

SELECT * FROM pg_extension;

Um eine Liste der spezifischen Erweiterungsversionen anzuzeigen, die zur Installation verfügbar sind, verwenden Sie die PostgreSQL-Ansicht pg_available_extension_versions in dem folgenden Befehl.

SELECT * FROM pg_available_extension_versions;