Upgrade von DB-Clustern von Amazon Aurora PostgreSQL - Amazon Aurora
Übersicht über die Upgrade-ProzesseAbrufen einer Liste der verfügbaren Upgrade-ZieleDurchführen eines Hauptversions-UpgradesVor der Durchführung eines Nebenversions-UpgradesSo führen Sie Upgrades von Nebenversionen durch und wenden Patches an Aktualisieren von PostgreSQL-ErweiterungenAlternatives Blau/Grün-Upgradeverfahren

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Upgrade von DB-Clustern von Amazon 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 (Automatic Minor Version Upgrade, AmVU) und darüber, wie Sie Ihren Aurora-DB-Cluster ändern, um diese verwenden zu können, 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 fordert Aurora Sie zu einem Upgrade auf, wenn eine neue Nebenversion in Ihrem veröffentlicht wird AWS-Region und Ihr Aurora PostgreSQL-DB-Cluster 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 in folgenden Fällen nicht unterstützt:

  • Wenn DB-Cluster von Aurora PostgreSQL als Aurora Serverless v1 konfiguriert sind.

  • Wenn Aurora PostgreSQL-DB-Cluster als globale Aurora-Datenbank in der Sekundärdatenbank konfiguriert sind. AWS-Regionen

  • Während des Upgrades von Reader-Instances in der globalen Aurora-Datenbank.

  • Während Betriebssystem-Patches und Betriebssystem-Upgrades.

ZDP wird für Aurora PostgreSQL-DB-Cluster unterstützt, die als konfiguriert sind. Aurora Serverless v2

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 Testen eines Upgrades 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.

Der Upgrade-Prozess beinhaltet die Möglichkeit eines kurzen Ausfalls, wenn alle Instances im Cluster auf die neue Version aktualisiert werden. 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.

DB-Cluster von Aurora PostgreSQL erfordern gelegentlich Betriebssystem-Updates. Diese Updates können eine neuere Version der Glibc-Bibliothek umfassen. Bei solchen Updates empfehlen wir Ihnen, die unter In Aurora PostgreSQL unterstützte Sortierungen beschriebenen Richtlinien zu befolgen.

Sie erhalten eine Liste der verfügbaren Versionen in Ihrem AWS-Region

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

FürLinux, oder: macOS Unix

aws rds describe-db-engine-versions \
  --engine aurora-postgresql \
  --engine-version version-number \
  --query 'DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}' \
  --output text

Windows:

aws rds describe-db-engine-versions ^
  --engine aurora-postgresql ^
  --engine-version version-number ^
  --query "DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}" ^
  --output text

Um beispielsweise die gültigen Upgrade-Ziele für einen Aurora PostgreSQL-DB-Cluster der Version 12.10 zu identifizieren, führen Sie den folgenden Befehl aus: AWS CLI

FürLinux, oder: macOS Unix

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

Windows:

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

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

Aktuelle Quellversion Upgrade-Ziele
15,5 16,1
15,4 16,1 15,5
15,3 16,1 15,5 15,4
15,2 16,1 15,5 15,4 15,3
14,10 16,1 15,5
14,9 16,1 15,5 15,4 14,10
14,8 16,1 15,5 15,4 15,3 15,2 14,10 14,9
14,7 16,1 15,5 15,4 15,3 15,2 14,10 14,9 14,8
14,6 16,1 15,5 15,4 15,3 15,2 14,10 14,9 14,8 14,7
14,5 16,1 15,5 15,4 15,3 15,2 14,10 14,9 14,8 14,7 14,6
14,4 16,1 15,5 15,4 15,3 15,2 14,10 14,9 14,8 14,7 14,6 14,5
14,3 16,1 15,5 15,4 15,3 15,2 14,10 14,9 14,8 14,7 14,6 14,5 14,4
13,13 16,1 15,5 14,10
13,12 16,1 15,5 15,4 14,10 14,9
13,11 16,1 15,5 15,4 15,3 14,10 14,9 14,8
13,10 16,1 15,5 15,4 15,3 15,2 14,10 14,9 14,8 14,7 13,13 13,12 13,11
13,9 16,1 15,5 15,4 15,3 15,2 14,10 14,9 14,8 14,7 14,6 13,11 13,10
13,8 16,1 15,5 15,4 15,3 15,2 14,10 14,9 14,8 14,7 14,6 14,5 13,13 13,12 13,11 13,10 13,9
13,7 16,1 15,5 15,4 15,3 15,2 14,10 14,9 14,8 14,7 14,6 14,5 14,4 14,3 13,13 13,12 13,11 13,10 13,9 13,8
12,17 16,1 15,5 14,10 13,13
12,16 16,1 15,5 15,4 14,10 14,9 13,13 13,12
12,15 16,1 15,5 15,4 15,3 14,10 14,9 14,8 13,13 13,12 13,11
12,14 16,1 15,5 15,4 15,3 15,2 14,10 14,9 14,8 14,7 13,13 13,12 13,11 13,10 12,15
12,13 16,1 15,5 15,4 15,3 15,2 14,10 14,9 14,8 14,7 14,6 13,13 13,12 13,11 13,10 13,9 12,17 12,16 12,15 12,14
12,12 16,1 15,5 15,4 15,3 15,2 14,10 14,9 14,8 14,7 14,6 14,5 13,13 13,12 13,11 13,10 13,9 12,17 12,16 12,15 13,8 12,15 12,14 12,13
12,11 16,1 15,5 15,4 15,3 15,2 14,10 14,9 14,8 14,7 14,5 14,4 14,3 13,13 13,12 13,11 13,10 13,9 13,8 13,7 12,15 12,14 12,13 12,12
12,9 16,1 15,5 15,4 15,3 15,2 14,10 14,9 14,8 14,7 13,13 13,12 13,11 13,10 13,9 13,8 13,7 12,17 12,16 12,15 12,14 12,13 12,12 12,11
11,12 16,1 15,5 15,4 14,10 14,9 13,13 13,12 12,17 12,16
11.9 16,1 15,5 15,4 15,3 15,2 14,10 14,9 14,8 14,7 14,6 13,13 13,12 13,11 13,10 13,9 12,17 12,16 12,15 12,14 12,13 12,12 12,11 12,09 11,21

Überprüfen Sie für jede Version, die Sie in Betracht ziehen, immer die Verfügbarkeit der DB-Instance-Klasse Ihres Clusters. Beispielsweise wird db.r4 für Aurora PostgreSQL 13 nicht unterstützt. Wenn Ihr DB-Cluster von Aurora PostgreSQL derzeit eine db.r4-Instance-Klasse verwendet, müssen Sie auf db.r5 umstellen, bevor Sie ein Upgrade ausführen. 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.

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. Eine genaue Liste der in Ihrer AWS-Region aktuellen Version verfügbaren Versionen erhalten Sie mit dem AWS CLI. Details hierzu finden Sie unter Sie erhalten eine Liste der verfügbaren Versionen in Ihrem 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 Testen eines Upgrades 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

Sie können ein Hauptversions-Upgrade von auf Babelfish für Aurora PostgreSQL 13 basierende Versionen ab 13.6 auf Versionen durchführen, die auf Aurora PostgreSQL 14 basieren, und zwar ab 14.6. Babelfish für Aurora PostgreSQL 13.4 und 13.5 unterstützen kein Hauptversions-Upgrade.

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

FürLinux, oder: macOS Unix

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

Windows:

aws rds describe-db-engine-versions ^
  --engine aurora-postgresql ^
  --engine-version version-number ^
  --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.

Testen eines Upgrades 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 oder mithilfe eines CLI-Befehls wie describe-db-instancesoder anzeigen describe-db-clusters.

  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.

      Wenn Sie ein Upgrade eines DB-Clusters mit Aurora-PostgreSQL-Version 10.x oder höher durchführen, für die die Erweiterung pg_repack Version 1.4.3 installiert ist, entfernen Sie diese Erweiterung, bevor Sie auf eine höhere Version aktualisieren.

  3. Suchen Sie nach den Datenbanken Template1 und Template0.

    Für ein erfolgreiches Upgrade müssen die Datenbanken Template 1 und Template 0 vorhanden sein und sollten als Vorlage aufgeführt werden. Verwenden Sie den folgenden Befehl, um dies zu überprüfen: 

    SELECT datname, datistemplate FROM pg_database; 
                        
datname    | datistemplate
-----------+---------------
template0  | t
rdsadmin   | f
template1  | t
postgres   | f

    In der Befehlsausgabe sollte der Wert datistemplate für die Datenbanken template1 und template0 t lauten.

  4. Entfernen von logischen Replikations-Slots.

    Der Upgrade-Vorgang kann nicht fortgesetzt werden, wenn der Aurora PostgreSQL DB-Cluster logische Replikations-Slots verwendet. Logische Replikationssteckplätze werden in der Regel für kurzfristige Datenmigrationsaufgaben verwendet, z. B. für die Migration von Daten mithilfe von 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);

    Für logische Replikationsszenarien, die die pglogical-Erweiterung verwenden, müssen außerdem Slots vom Herausgeberknoten gelöscht werden, damit ein Hauptversions-Upgrade auf diesem Knoten erfolgreich durchgeführt werden kann. Sie können den Replikationsprozess jedoch nach dem Upgrade vom Abonnentenknoten aus neu starten. Weitere Informationen finden Sie unter Wiederherstellung der logischen Replikation nach einem Hauptversions-Upgrade.

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

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

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

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

  9. 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. Sie können die Ausführungspläne auf der duplizierten Testinstance auf mögliche Regressionen des Ausführungsplans überwachen und deren Leistung bewerten. 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.

  10. 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. Während dieses Vorgangs können Sie Ihren Cluster nicht point-in-time wiederherstellen. Später können Sie die Zeiten vor Beginn des Upgrades und nach Abschluss des automatischen Snapshots Ihrer Instance point-in-time wiederherstellen. Sie können jedoch keine point-in-time Wiederherstellung auf eine frühere Nebenversion 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.

  11. 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. Führen Sie diesen Schritt für jede Datenbank auf all Ihren PostgreSQL-DB-Instances durch. Optimizer-Statistiken werden während eines Hauptversionsupgrades nicht übertragen, daher müssen Sie alle Statistiken neu generieren, um Leistungsprobleme zu vermeiden. Führen Sie den Befehl ohne Parameter aus, um Statistiken für alle regulären Tabellen in der aktuellen Datenbank wie folgt zu generieren:

    ANALYZE VERBOSE;

    Das Flag VERBOSE ist optional, aber wenn Sie es verwenden, wird Ihnen der Fortschritt angezeigt. Weitere Informationen finden Sie unter ANALYZE in der PostgreSQL-Dokumentation.

    Anmerkung

    Führen Sie ANALYZE nach dem Upgrade auf Ihrem System aus, um Leistungsprobleme zu vermeiden.

  • 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 aktualisieren, indem Sie die AWS Management Console 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 Amazon RDS-Konsole an AWS Management Console und öffnen Sie sie 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 Ändern aus. Die Seite 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.

Verwenden Sie den modify-db-cluster AWS CLI Befehl, um die Engine-Version eines DB-Clusters zu aktualisieren. 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 describe-db-engine-versionsBefehl, um Informationen zu gültigen 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 LinuxmacOS, oderUnix:

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

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 Verwenden Sie den Vorgang DescribeDB, um Informationen zu gültigen Engine-Versionen zu EngineVersions erhalten.

  • 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 Testen eines Upgrades Ihres Produktions-DB-Clusters auf eine neue Hauptversion ausführlich beschrieben. Stellen Sie sicher, dass Sie Ihre DB-Cluster-Parametergruppen- und DB-Parametergruppen-Einstellungen für jeden AWS-Region in Ihrer globalen Aurora-Datenbank vor dem Upgrade vorbereiten, wie unter beschriebenTesten eines Upgrades Ihres Produktions-DB-Clusters auf eine neue Hauptversion. step 1.

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 modify-global-cluster AWS CLI Befehl, um das Upgrade für Ihre globale Aurora-Datenbank zu starten, indem Sie den verwenden AWS CLI.

  • Verwenden Sie die ModifyGlobalClusterAPI, um das Upgrade zu starten.

Vor der Durchführung eines kleineren Versions-Upgrades

Wir empfehlen Ihnen, die folgenden Aktionen durchzuführen, um die Ausfallzeit während eines Upgrades einer Nebenversion zu reduzieren:

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

Kleinere Versions-Upgrades und Patches sind AWS-Regionen erst nach gründlichen Tests verfügbar. 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. Informationen zum Festlegen der Einstellung Automatisches Unterversion-Upgrade und zur Funktionsweise der Einstellung, wenn sie auf Cluster- und Instance-Ebene angewendet wird, finden Sie unter  Automatische Nebenversions-Upgrades für Aurora-DB-Cluster.

Sie können den Wert der Option auto Upgrade der Nebenversion aktivieren für all Ihre Aurora PostgreSQL-DB-Cluster überprüfen, indem Sie den describe-db-instances AWS CLI Befehl 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. Bei dem abgebildeten Befehl wird davon ausgegangen, dass Sie Ihre AWS CLI Konfiguration so konfiguriert haben, dass sie auf Ihre Standardeinstellung abzielt. AWS-Region

Weitere Informationen zur AmVU-Option und darüber, wie Sie Ihren Aurora-DB-Cluster ändern, um diese u verwenden zu können, 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 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.

Die folgende Tabelle zeigt die Aurora-PostgreSQL-Versionen und DB-Instance-Klassen, in denen ZDP verfügbar ist:

Version db.r*-Instance-Klassen db.t*-Instance-Klassen db.x*-Instance-Klassen db.serverless-Instance-Klasse
10.21.0 und höhere 10.21-Versionen Ja Ja Ja N/A
11.16.0 und höhere 11.16-Versionen Ja Ja Ja N/A
11.17 und höhere Versionen Ja Ja Ja N/A
12.11.0 und höhere 12.11-Versionen Ja Ja Ja N/A
12.12 und höhere Versionen Ja Ja Ja N/A
13.7.0 und höhere 13.7-Versionen Ja Ja Ja N/A
13.8 und höhere Versionen Ja Ja Ja Ja
14.3.1 und höhere 14.3-Versionen Ja Ja Ja N/A
14.4.0 und höhere 14.4-Versionen Ja Ja Ja N/A
14.5 und höhere Versionen Ja Ja Ja Ja
15.3 und höhere Versionen Ja Ja Ja Ja

ZDP arbeitet, indem es die aktuellen Client-Verbindungen zu Ihrem Aurora-PostgreSQL-DB-Cluster während des Aurora-PostgreSQL-Upgrade-Prozesses beibehält. In den folgenden Fällen werden die Verbindungen jedoch unterbrochen, damit ZDP den Vorgang abschließen kann:

  • Wenn lang dauernde Abfragen oder Transaktionen ausgeführt werden.

  • Data Definition Language (DDL)-Anweisungen werden ausgeführt.

  • Es werden temporäre Tabellen verwendet oder Tabellensperren sind aktiv.

  • Alle Sitzungen überwachen Benachrichtigungskanäle.

  • Ein Cursor mit dem Status 'WITH HOLD' wird verwendet.

  • Es werden TLSv1.3- oder TLSv1.1-Verbindungen verwendet.

Während des Upgrade-Vorgangs mit ZDP sucht die Datenbank-Engine nach einem ruhigen Punkt, um alle neuen Transaktionen anzuhalten. Diese Aktion schützt die Datenbank bei Patches und Upgrades. Um sicherzustellen, dass Ihre Anwendungen bei unterbrochenen Transaktionen reibungslos laufen, empfehlen wir, die Logik für Wiederholversuche in Ihren Code zu integrieren. Dieser Ansatz stellt sicher, dass das System kurze Ausfallzeiten ohne Fehler bewältigen und die neuen Transaktionen nach dem Upgrade erneut versuchen kann.

Wenn ZDP erfolgreich abgeschlossen wird, werden Anwendungssitzungen, mit Ausnahme von Sitzungen mit unterbrochenen Verbindungen, beibehalten und die Datenbank-Engine wird während des laufenden Upgrades neu gestartet. Der Neustart der Datenbank-Engine kann zwar zu einem vorübergehenden 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. Parameteränderungen, die sich auf Ihrem DB-Cluster von Aurora PostgreSQL oder dessen Instances im Status pending befinden, beeinträchtigen ebenfalls 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 mithilfe der Konsole, der oder der RDS-API auf eine neue Nebenversion aktualisieren. AWS CLI 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 Amazon RDS-Konsole an AWS Management Console und öffnen Sie sie 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 Ändern aus. Die Seite 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.

Um die Engine-Version eines DB-Clusters zu aktualisieren, verwenden Sie den modify-db-cluster AWS CLI Befehl 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 describe-db-engine-versionsBefehl, um Informationen zu gültigen Engine-Versionen zu erhalten.

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

Für LinuxmacOS, oderUnix:

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

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 Verwenden Sie den Vorgang DescribeDB, um Informationen zu gültigen Engine-Versionen zu EngineVersions erhalten.

  • 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 DB-Cluster von Aurora PostgreSQL auf eine neue Haupt- oder Nebenversion aktualisieren, werden die PostgreSQL-Erweiterungen nicht gleichzeitig aktualisiert. Bei den meisten Erweiterungen aktualisieren Sie die Erweiterung, nachdem das Upgrade der Haupt- oder Nebenversion 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 Testen eines Upgrades 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

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

Um die pg_repack-Erweiterung zu aktualisieren, entfernen Sie die Erweiterung und erstellen Sie eine neue Version in der aktualisierten DB-Instance. Weitere Informationen finden Sie unter pg_repack installation in der pg_repack-Dokumentation.

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;

Alternatives Blau/Grün-Upgradeverfahren

In einigen Situationen ist es Ihre oberste Priorität, eine sofortige Umstellung vom alten auf einen aktualisierten Cluster durchzuführen. In solchen Situationen können Sie einen mehrstufigen Prozess verwenden, der die alten und neuen Cluster ausführt. side-by-side Hier replizieren Sie Daten vom alten auf den neuen Cluster, bis der neuen Cluster zur Übernahme bereit ist. Details hierzu finden Sie unter Verwendung von Blau/Grün-Bereitstellungen von Amazon RDS für Datenbankaktualisierungen.