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.

# Aktualisierungen der Datenbank-Engine für Amazon Aurora PostgreSQL
Aurora PostgreSQL-Aktualisierungen<a name="pgsql_relnotes"></a>

Nachstehend finden Sie Informationen zu Versionen und Aktualisierungen der Amazon-Aurora-PostgreSQL-Engine. Sie erfahren auch, wie Sie Ihre Aurora-PostgreSQL-Engine aktualisieren. Weitere Informationen zu Aurora-Versionen im Allgemeinen finden Sie unter [Amazon-Aurora-Versionen](Aurora.VersionPolicy.md).

**Tipp**  
Sie können die für ein DB-Cluster-Upgrade erforderlichen Ausfallzeiten minimieren, indem Sie eine Blau/Grün-Bereitstellung verwenden. Weitere Informationen finden Sie unter [Verwenden von Amazon Aurora Blue/Green Deployments für Datenbank-Updates](blue-green-deployments.md).

**Topics**
+ [

## Identifizieren der Versionen von Amazon Aurora PostgreSQL
](#AuroraPostgreSQL.Updates.Versions)
+ [

# Amazon Aurora PostgreSQL Releases und Engine Versionen
](AuroraPostgreSQL.Updates.20180305.md)
+ [

# Erweiterungsversionen für Amazon Aurora PostgreSQL
](AuroraPostgreSQL.Extensions.md)
+ [

# Upgrade von DB-Clustern von Amazon Aurora PostgreSQL
](USER_UpgradeDBInstance.PostgreSQL.md)
+ [

# Verwenden einer Aurora PostgreSQL Long-Term Support (LTS, Langzeit-Support)-Version
](AuroraPostgreSQL.Updates.LTS.md)

## Identifizieren der Versionen von Amazon Aurora PostgreSQL


Amazon Aurora enthält bestimmte Funktionen, die für Aurora allgemein sind und für alle Aurora-DB-Cluster verfügbar sind. Amazon Aurora umfasst andere Funktionen, die spezifisch für eine bestimmte Datenbank-Engine sind, die Aurora unterstützt. Diese Funktionen stehen nur denjenigen Aurora-DB-Clustern zur Verfügung, die diese Datenbank-Engine verwenden, wie z. B. Aurora PostgreSQL.

Eine Aurora-Datenbank-Version hat normalerweise zwei Versionsnummern, die Aurora-Versionsnummer und die Versionsnummer der Datenbank-Engine. Wenn eine Aurora-PostgreSQL-Version eine Aurora-Versionsnummer hat, befindet sie sich in der [Amazon Aurora PostgreSQL Releases und Engine Versionen](AuroraPostgreSQL.Updates.20180305.md)-Auflistung hinter der Engine-Versionsnummer. 

**Topics**
+ [

### Aurora-Versionsnummer
](#AuroraPostgreSQL.Updates.Versions.AuroraNumber)
+ [

### Versionsnummern der PostgreSQL-Engine
](#AuroraPostgreSQL.Updates.Versions.EngineNumber)

### Aurora-Versionsnummer


Aurora-Versionsnummern verwenden die*major*. *minor*. *patch*Benennungsschema. Eine Aurora-Patch-Version enthält wichtige Bugfixes, die einer Nebenversion nach ihrer Veröffentlichung hinzugefügt werden. Weitere Informationen zu Haupt-, Neben- und Patch-Versionen von Amazon Aurora finden Sie unter [Amazon-Aurora-Hauptversionen](Aurora.VersionPolicy.Versioning.md#Aurora.VersionPolicy.MajorVersions), [Amazon-Aurora-Nebenversionen](Aurora.VersionPolicy.Versioning.md#Aurora.VersionPolicy.MinorVersions) und [Amazon-Aurora-Patchversionen](Aurora.VersionPolicy.Versioning.md#Aurora.VersionPolicy.PatchVersions). 

Sie können die Aurora-Versionsnummer Ihrer Aurora-PostgreSQL-DB-Instance mit der folgenden SQL-Abfrage herausfinden:

```
postgres=> SELECT aurora_version();
```

Ab der Veröffentlichung der PostgreSQL-Versionen 13.3, 12.8, 11.13 und 10.18 und für alle späteren Versionen sind die Aurora-Versionsnummern genauer auf die PostgreSQL-Engine-Version abgestimmt. Wenn Sie beispielsweise einen Aurora-PostgreSQL-13.3-DB-Cluster abfragen, wird Folgendes zurückgegeben:

```
aurora_version
----------------
 13.3.1
(1 row)
```

Frühere Versionen, wie Aurora-PostgreSQL-10.14-DB-Cluster, liefern Versionsnummern wie folgende:

```
aurora_version
----------------
 2.7.3
(1 row)
```

### Versionsnummern der PostgreSQL-Engine


Ab PostgreSQL 10 verwenden Versionen der PostgreSQL-Datenbank-Engine a. *major* *minor*Nummerierungsschema für alle Versionen. Beispiele: PostgreSQL 10.18, PostgreSQL 12.7 und PostgreSQL 13.3. 

Versionen vor PostgreSQL 10 verwendeten a. *major* *major*. *minor*Nummerierungsschema, bei dem die ersten beiden Ziffern die Hauptversionsnummer bilden und eine dritte Ziffer eine Nebenversion bezeichnet. PostgreSQL 9.6 war beispielsweise eine Hauptversion, wobei die Nebenversionen 9.6.21 oder 9.6.22 durch die dritte Ziffer gekennzeichnet waren.

**Anmerkung**  
Die PostgreSQL-Engine-Version 9.6 wird nicht mehr unterstützt. Informationen zum Upgrade finden Sie unter [Upgrade von DB-Clustern von Amazon Aurora PostgreSQL](USER_UpgradeDBInstance.PostgreSQL.md). Versionsrichtlinien und Release-Zeitpläne finden Sie unter [Wie lange bleiben Amazon-Aurora-Hauptversionen verfügbar?](Aurora.VersionPolicy.Versioning.md#Aurora.VersionPolicy.MajorVersionLifetime).

Sie können die PostgreSQL-Datenbank-Engine-Versionsnummer mit der folgenden SQL-Abfrage herausfinden:

```
postgres=> SELECT version();
```

Für einen Aurora-PostgreSQL-13.3-DB-Cluster sind die Ergebnisse wie folgt:

```
version
-------------------------------------------------------------------------------------------------
 PostgreSQL 13.3 on x86_64-pc-linux-gnu, compiled by x86_64-pc-linux-gnu-gcc (GCC) 7.4.0, 64-bit
(1 row)
```

# Amazon Aurora PostgreSQL Releases und Engine Versionen
Aurora PostgreSQL Veröffentlichungen

Versionen der Amazon-Aurora-PostgreSQL-kompatiblen Edition werden regelmäßig aktualisiert. Updates werden auf Aurora-PostgreSQL-DB-Cluster während des Wartungszeitraums angewendet. Wann Updates angewendet werden, hängt von der Art des Updates, der Einstellung und der AWS-Region Einstellung des Wartungsfensters für den DB-Cluster ab. Viele der aufgelisteten Versionen enthalten sowohl eine PostgreSQL-Versionsnummer als auch eine Amazon-Aurora-Versionsnummer. Ab der Veröffentlichung der PostgreSQL-Versionen 13.3, 12.8, 11.13, 10.18 und für alle anderen späteren Versionen werden jedoch keine Aurora-Versionsnummern mehr verwendet. Informationen zum Ermitteln der Versionsnummern Ihrer Aurora-PostgreSQL-Datenbank finden Sie unter [Identifizieren der Versionen von Amazon Aurora PostgreSQL](AuroraPostgreSQL.Updates.md#AuroraPostgreSQL.Updates.Versions). 

Hinweise zu Erweiterungen und Modulen finden Sie unter [Erweiterungsversionen für Amazon Aurora PostgreSQL](AuroraPostgreSQL.Extensions.md).

**Anmerkung**  
Informationen zu den Versionsrichtlinien und Veröffentlichungszeitplänen von Amazon Aurora finden Sie unter [Wie lange bleiben Amazon-Aurora-Hauptversionen verfügbar?](Aurora.VersionPolicy.Versioning.md#Aurora.VersionPolicy.MajorVersionLifetime). 

Informationen zur Unterstützung von Amazon Aurora finden Sie unter [Amazon RDS FAQs](https://aws.amazon.com/rds/faqs/). 

Verwenden Sie den Befehl, um festzustellen, welche Versionen der Aurora PostgreSQL-DB-Engine in einer AWS-Region verfügbar sind. [describe-db-engine-versions](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-engine-versions.html) AWS CLI Beispiel:

```
aws rds describe-db-engine-versions --engine aurora-postgresql --query '*[].[EngineVersion]' --output text --region aws-region
```

Eine Liste von finden Sie unter AWS-Regionen. [Aurora PostgreSQL-Verfügbarkeit in Regionen](Concepts.RegionsAndAvailabilityZones.md#Aurora.Overview.Availability.PostgreSQL)

Weitere Informationen zu den PostgreSQL-Versionen, die in Aurora PostgreSQL verfügbar sind, finden Sie in den [https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/Welcome.html](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/Welcome.html).

# Erweiterungsversionen für Amazon Aurora PostgreSQL
Erweiterungsversionen für Aurora PostgreSQL

Sie können verschiedene PostgreSQL-Erweiterungen installieren und konfigurieren, um sie mit Aurora-PostgreSQL-DB-Clustern zu verwenden. Sie können beispielsweise die PostgreSQL-Erweiterung `pg_partman` verwenden, um die Erstellung und Pflege von Tabellenpartitionen zu automatisieren. Weitere Informationen über diese und andere für Aurora PostgreSQL verfügbare Erweiterungen finden Sie unter [Arbeiten mit Erweiterungen und Fremddaten-Wrappern](Appendix.PostgreSQL.CommonDBATasks.md).

Weitere Informationen zu den PostgreSQL-Erweiterungen, die von Aurora PostgreSQL unterstützt werden, finden Sie unter [Versionen der Erweiterungen für Amazon Aurora PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Extensions.html) in den *Versionshinweisen für Aurora PostgreSQL*.

# Upgrade von DB-Clustern von Amazon Aurora PostgreSQL
Upgrade von DB-Clustern von Amazon Aurora PostgreSQL<a name="pgsql_upgrade"></a>

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. 

**Contents**
+ [

## Übersicht über die Upgrade-Prozesse für Aurora-PostgreSQL
](#USER_UpgradeDBInstance.PostgreSQL.Overview)
+ [

# Abrufen einer Liste der verfügbaren Versionen in Ihrem AWS-Region
](USER_UpgradeDBInstance.PostgreSQL.UpgradeVersion.md)
+ [

# Durchführen eines Hauptversions-Upgrades
](USER_UpgradeDBInstance.PostgreSQL.MajorVersion.md)
  + [

## Testen eines Upgrades Ihres Produktions-DB-Clusters auf eine neue Hauptversion
](USER_UpgradeDBInstance.PostgreSQL.MajorVersion.md#USER_UpgradeDBInstance.PostgreSQL.MajorVersion.Upgrade.preliminary)
  + [

## Empfehlungen für die Zeit nach dem Upgrade
](USER_UpgradeDBInstance.PostgreSQL.MajorVersion.md#USER_UpgradeDBInstance.PostgreSQL.MajorVersion.Upgrade.postupgrade)
  + [

## Upgrade der Aurora-PostgreSQL-Engine auf eine neue Hauptversion
](USER_UpgradeDBInstance.PostgreSQL.MajorVersion.md#USER_UpgradeDBInstance.Upgrading.Manual)
    + [

### Hauptversions-Upgrades für globale Datenbanken
](USER_UpgradeDBInstance.PostgreSQL.MajorVersion.md#USER_UpgradeDBInstance.PostgreSQL.GlobalDB)
+ [

# Durchführen eines Nebenversions-Upgrades
](USER_UpgradeDBInstance.PostgreSQL.MinorUpgrade.md)
  + [

## Vor dem Durchführen eines Nebenversions-Upgrades
](USER_UpgradeDBInstance.PostgreSQL.MinorUpgrade.md#USER_UpgradeDBInstance.PostgreSQL.BeforeMinor)
  + [

## So führen Sie Upgrades von Nebenversionen durch und wenden Patches an
](USER_UpgradeDBInstance.PostgreSQL.MinorUpgrade.md#USER_UpgradeDBInstance.PostgreSQL.Minor)
  + [

## Nebenversions-Upgrades und Zero-Downtime-Patching
](USER_UpgradeDBInstance.PostgreSQL.MinorUpgrade.md#USER_UpgradeDBInstance.PostgreSQL.Minor.zdp)
  + [

## Einschränkungen des Patchens ohne Ausfallzeiten
](USER_UpgradeDBInstance.PostgreSQL.MinorUpgrade.md#USER_UpgradeDBInstance.PostgreSQL.Minor.zdp.limitations)
  + [

## Durchführen eines Upgrades der Aurora-PostgreSQL-Engine auf eine neue Nebenversion
](USER_UpgradeDBInstance.PostgreSQL.MinorUpgrade.md#USER_UpgradeDBInstance.MinorUpgrade)
+ [

# Aktualisieren von PostgreSQL-Erweiterungen
](USER_UpgradeDBInstance.Upgrading.ExtensionUpgrades.md)
+ [

## Alternative blue/green Upgrade-Technik
](#USER_UpgradeDBInstance.Upgrading.BlueGreen)

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

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.   
Upgrades von Nebenversionen können von Aurora automatisch angewendet werden. Wenn Sie einen neuen Aurora-PostgreSQL-DB-Cluster erstellen, ist die Option **Nebenversions-Upgrade aktivieren** standardmäßig aktiviert. Sofern Sie diese Option nicht manuell deaktivieren, führt Aurora während Ihres geplanten Wartungsfensters regelmäßig automatische Upgrades von Nebenversionen durch. 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](USER_UpgradeDBInstance.Maintenance.md#Aurora.Maintenance.AMVU).  
Wenn das automatische Upgrade der Nebenversion für Ihren Aurora-PostgreSQL-DB-Cluster nicht aktiviert ist, wird Aurora PostgreSQL nicht automatisch auf die neue Nebenversion aktualisiert. Stattdessen werden Sie von Aurora zum Upgrade aufgefordert, wenn eine neue Nebenversion in Ihrer AWS-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](USER_UpgradeDBInstance.PostgreSQL.MinorUpgrade.md#USER_UpgradeDBInstance.PostgreSQL.Minor).   
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.  
Automatische Nebenversions-Upgrades werden auf die standardmäßige Nebenversion durchgeführt.
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](USER_UpgradeDBInstance.PostgreSQL.MinorUpgrade.md#USER_UpgradeDBInstance.PostgreSQL.Minor.zdp). Weitere Informationen zu den unterstützten Features und Einschränkungen von ZDP finden Sie unter [Einschränkungen des Patchens ohne Ausfallzeiten](USER_UpgradeDBInstance.PostgreSQL.MinorUpgrade.md#USER_UpgradeDBInstance.PostgreSQL.Minor.zdp.limitations).

**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](USER_UpgradeDBInstance.PostgreSQL.MajorVersion.md#USER_UpgradeDBInstance.PostgreSQL.MajorVersion.Upgrade.preliminary) 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 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](USER_UpgradeDBInstance.PostgreSQL.MajorVersion.md).

**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 Betriebssystemupdates. Diese Updates können eine neuere Version der Glibc-Bibliothek umfassen. Bei solchen Updates empfehlen wir Ihnen, die unter [](PostgreSQL-Collations.md) beschriebenen Richtlinien zu befolgen. 

# Abrufen einer Liste der verfügbaren Versionen in Ihrem AWS-Region
Abrufen einer Liste der verfügbaren Upgrade-Ziele

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](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-engine-versions.html) AWS CLI folgenden Befehl abfragen.

Für Linux, macOS oder Unix:

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

Für 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ür Linux, macOS oder Unix:

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

Für Windows:

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

In der folgenden Tabelle finden Sie die Ziele der Haupt- und Nebenversions-Upgrades, die für verschiedene Aurora-PostgreSQL-DB-Versionen verfügbar sind. Um die Kompatibilität aufrechtzuerhalten, werden nicht alle Versionen als Upgrade-Ziele angeboten. Aurora PostgreSQL führt mit jeder vierteljährlichen Veröffentlichung von Nebenversionen neue Features und Bugfixes ein. Weitere Informationen zu Nebenversionen von Aurora-PostgreSQL finden Sie unter [https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/Welcome.html](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/Welcome.html). 


| Aktuelle Quellversion | Upgrade-Ziele | 
| --- | --- | 
| 17.7 |  Keine  | 
| 17,6 |  [17,7](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version177x)  | 
| 17,5 |  [17,7](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version177x)[, 17,6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version176x)  | 
| 17,4 |  [17,7, 17,6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version177x)[, [17,5](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version176x)](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version175x)  | 
| 16,11 |  Keine  | 
| 16,10 |  [17,7](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version177x) [16,11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1611x)  | 
| 16,9 |  [17,7](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version177x) [16,11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1611x) [https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1610x](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1610x)  | 
| 16,8 |  [17,7](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version177x) [16,11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1611x) [https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version174x](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version174x)  | 
| 16,6 |  [17,7](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version177x) [16,11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1611x) [https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version174x](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version174x)  | 
| 16,4 |  [17,7](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version177x) [16,11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1611x) [https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version169x](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version169x)  | 
| 16,3 |  [17,7](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version177x) [16,11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1611x) [https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version168x](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version168x)  | 
| 16,2 |  [17,7](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version177x) [16,11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1611x) [https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version168x](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version168x)  | 
| 16,1 |  [17,7](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version177x) [16,11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1611x) [https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version166x](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version166x)  | 
| 15,15 |  Keine  | 
| 15,14 |  [17,7](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version177x) [16,11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1611x) [15,15](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1515x)  | 
| 15,13 |  [17,7](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version177x) [16,11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1611x) [https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1514x](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1514x)  | 
| 15,12 |  [17,7](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version177x) [16,11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1611x) [https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1514x](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1514x)  | 
| 15,10 |  [17,7](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version177x) [16,11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1611x) [https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version174x](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version174x)  | 
| 15,11 |  [17,7](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version177x) [16,11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1611x) [https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version168x](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version168x)  | 
| 14,20 |  Keine  | 

Ü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 Aurora PostgreSQL-DB-Cluster derzeit eine db.r4-Instance-Klasse verwendet, müssen Sie sie so ändern, dass sie eine unterstützte DB-Instance-Klasse verwendet, bevor Sie ein Upgrade auf Aurora PostgreSQL 13 durchführen können. Weitere Informationen zu den verfügbaren Aurora PostgreSQL-DB-Instance-Klassen, einschließlich der Klassen, die Graviton2-basiert und welche Intel-basiert sind, finden Sie unter. [Amazon Aurora Aurora-DB-Instance-Klassen](Concepts.DBInstanceClass.md)

# Durchführen eines Hauptversions-Upgrades
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 in Ihrer AWS-Region für Ihre aktuelle Version verfügbaren Versionen abrufen, indem Sie die verwenden AWS CLI. Details hierzu finden Sie unter [Abrufen einer Liste der verfügbaren Versionen in Ihrem AWS-Region](USER_UpgradeDBInstance.PostgreSQL.UpgradeVersion.md). 

1. 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](#USER_UpgradeDBInstance.PostgreSQL.MajorVersion.Upgrade.preliminary).

1. 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](#USER_UpgradeDBInstance.Upgrading.Manual).

**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](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-engine-versions.html) AWS CLI folgenden Befehl abfragen.

Für Linux, macOS oder Unix:

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

Für 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](USER_UpgradeDBInstance.PostgreSQL.UpgradeVersion.md#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
Testen eines Upgrades Ihres 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](AuroraPostgreSQL.Optimize.BestPractice.md#AuroraPostgreSQL.Optimize.BestPractice.MajorVersionUpgrade) 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. 

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

1. Suchen Sie nach ungültigen Datenbanken und löschen Sie alle vorhandenen. 

   Die Spalte `datconnlimit` im Katalog `pg_database` enthält den Wert `-2`, um Datenbanken, die während eines `DROP DATABASE`-Vorgangs unterbrochen wurden, als ungültig zu kennzeichnen. Verwenden Sie die folgende Abfrage, um zu überprüfen, ob ungültige Datenbanken vorhanden sind. 

   ```
   SELECT
       datname
   FROM
       pg_database
   WHERE
       datconnlimit = - 2;
   ```

   Wenn die Abfrage Datenbanknamen zurückgibt, sind diese Datenbanken ungültig. Verwenden Sie die `DROP DATABASE invalid_db_name`-Anweisung, um ungültige Datenbanken zu löschen. Sie können die folgende dynamische Anweisung ausführen, um alle ungültigen Datenbanken zu löschen.

   ```
   SELECT
       'DROP DATABASE ' || quote_ident(datname) || ';'
   FROM
       pg_database
   WHERE
       datconnlimit = -2 \gexec
   ```

1. 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\$1*-Datentypen, bevor Sie versuchen, einen Upgrade durchzuführen. Bis auf `regtype` und `regclass` ist kein Upgrade der *reg\$1*-Datentypen möglich. Das Dienstprogramm pg\$1upgrade (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\$1upgrade](https://www.postgresql.org/docs/current/pgupgrade.html) in der PostgreSQL-Dokumentation.

     Um zu überprüfen, dass keine Anwendungen der nicht unterstützten *reg\$1*-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.

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

1. 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](Appendix.PostgreSQL.CommonDBATasks.pglogical.recover-replication-after-upgrade.md).

1. 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](USER_CreateSnapshotCluster.md).

1. 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](USER_UpgradeDBInstance.Upgrading.ExtensionUpgrades.md). Weitere Informationen zum Aktualisieren von PostGIS finden Sie unter[Schritt 6: Upgrade der PostGIS-Erweiterung](Appendix.PostgreSQL.CommonDBATasks.PostGIS.md#Appendix.PostgreSQL.CommonDBATasks.PostGIS.Update). 

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

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

1. 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](aurora-restore-snapshot.md#aurora-restore-snapshot.Restoring) oder [Klonen eines Volumes für einen Amazon-Aurora-DB-Cluster](Aurora.Managing.Clone.md).

   Weitere Informationen finden Sie unter [Upgrade der Aurora-PostgreSQL-Engine auf eine neue Hauptversion](#USER_UpgradeDBInstance.Upgrading.Manual). 

1. 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](#USER_UpgradeDBInstance.Upgrading.Manual). 

   
**Anmerkung**  
Während des Upgrade-Prozesses erstellt Aurora PostgreSQL einen DB-Cluster-Snapshot. 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\$1upgrade-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](USER_LogAccess.md).

1. Aktualisieren Sie PostgreSQL-Erweiterungen. Bei einem PostgreSQL-Upgrade-Prozess werden keine PostgreSQL-Erweiterungen aktualisiert. Weitere Informationen finden Sie unter [Aktualisieren von PostgreSQL-Erweiterungen](USER_UpgradeDBInstance.Upgrading.ExtensionUpgrades.md).

## Empfehlungen für die Zeit nach dem Upgrade
Empfehlungen für die Zeit nach dem Upgrade

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](https://www.postgresql.org/docs/10/sql-analyze.html) in der PostgreSQL-Dokumentation. 

  Wenn Sie bestimmte Tabellen analysieren, anstatt ANALYZE VERBOSE zu verwenden, führen Sie den Befehl ANALYZE für jede Tabelle wie folgt aus:

  ```
  ANALYZE table_name;
  ```

  Analysieren Sie bei partitionierten Tabellen immer die übergeordnete Tabelle. Dieser Prozess beinhaltet Folgendes:
  + Automatisches Stichprobenverfahren für Zeilen in allen Partitionen
  + Rekursives Aktualisieren der Statistiken für jede Partition
  + Verwalten wichtiger Planungsstatistiken auf übergeordneter Ebene

  In übergeordneten Tabellen werden zwar keine tatsächlichen Daten gespeichert, ihre Analyse ist jedoch für die Abfrageoptimierung von entscheidender Bedeutung. Wenn ANALYZE nur auf einzelnen Partitionen ausgeführt wird, kann dies zu einer schlechten Abfrageleistung führen, da der Optimierer nicht über die umfassenden Statistiken verfügt, die für eine effiziente partitionsübergreifende Planung erforderlich sind.
**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
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](aurora-restore-snapshot.md) und [Wiederherstellen eines DB-Clusters zu einer bestimmten Zeit](aurora-pitr.md). 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\$1upgrade. 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\$1upgrade](https://www.postgresql.org/docs/current/pgupgrade.html) in der PostgreSQL-Dokumentation. 

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

### Konsole


**So führen Sie ein Upgrade der Engine-Version eines DB-Clusters durch**

1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Amazon RDS-Konsole unter [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).

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

1. Wählen Sie **Ändern** aus. Die Seite **DB-Cluster ändern** wird angezeigt.

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

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

1. 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](Aurora.Modifying.md). 

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

### AWS CLI


Verwenden Sie den [modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html) 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-versions](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-engine-versions.html)Befehl, 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`. 

**Example**  
Für Linux, macOS oder Unix:  

```
1. aws rds modify-db-cluster \
2.     --db-cluster-identifier mydbcluster \
3.     --engine-version new_version \
4.     --allow-major-version-upgrade \
5.     --no-apply-immediately
```
Für Windows:  

```
1. aws rds modify-db-cluster ^
2.     --db-cluster-identifier mydbcluster ^
3.     --engine-version new_version ^
4.     --allow-major-version-upgrade ^
5.     --no-apply-immediately
```

### RDS-API


Verwenden Sie den DBCluster Vorgang [Modify](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html), um die Engine-Version eines DB-Clusters zu aktualisieren. 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 Informationen zu gültigen Engine-Versionen erhalten Sie mit dem Vorgang [DBEngineDescribe Versions](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBEngineVersions.html).
+ `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](#USER_UpgradeDBInstance.PostgreSQL.MajorVersion.Upgrade.preliminary) ausführlich beschrieben. Stellen Sie sicher, dass Sie Ihre DB-Cluster-Parametergruppe und die DB-Parametergruppen-Einstellungen für jeden AWS-Region in Ihrer globalen Aurora-Datenbank vor dem Upgrade vorbereiten, wie unter beschrieben[Testen eines Upgrades Ihres Produktions-DB-Clusters auf eine neue Hauptversion](#USER_UpgradeDBInstance.PostgreSQL.MajorVersion.Upgrade.preliminary). [step 1.](#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](aurora-global-database-disaster-recovery.md#aurora-global-database-manage-recovery).

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](#USER_UpgradeDBInstance.Upgrading.Manual). 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\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/images/aurora-global-database-plus-other.png)


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\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/images/aurora-global-db-apg-upgrade-2.png)


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](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-global-cluster.html) AWS CLI Befehl, um das Upgrade für Ihre globale Aurora-Datenbank zu starten, indem Sie den verwenden AWS CLI. 
+ Verwenden Sie die [ModifyGlobalCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyGlobalCluster.html)API, um das Upgrade zu starten. 

# Durchführen eines Nebenversions-Upgrades
Durchführen eines Hauptversions-Upgrades

Sie können die folgenden Methoden verwenden, um die Nebenversion eines DB-Clusters zu aktualisieren oder einen DB-Cluster zu patchen: 

**Topics**
+ [

## Vor dem Durchführen eines Nebenversions-Upgrades
](#USER_UpgradeDBInstance.PostgreSQL.BeforeMinor)
+ [

## So führen Sie Upgrades von Nebenversionen durch und wenden Patches an
](#USER_UpgradeDBInstance.PostgreSQL.Minor)
+ [

## Nebenversions-Upgrades und Zero-Downtime-Patching
](#USER_UpgradeDBInstance.PostgreSQL.Minor.zdp)
+ [

## Einschränkungen des Patchens ohne Ausfallzeiten
](#USER_UpgradeDBInstance.PostgreSQL.Minor.zdp.limitations)
+ [

## Durchführen eines Upgrades der Aurora-PostgreSQL-Engine auf eine neue Nebenversion
](#USER_UpgradeDBInstance.MinorUpgrade)

## Vor dem Durchführen eines Nebenversions-Upgrades
Vor dem Durchführen eines Nebenversions-Upgrades

Wir empfehlen Ihnen, die folgenden Aktionen durchzuführen, um die Ausfallzeit während eines Unterversion-Upgrades zu reduzieren:
+ Die Wartung des Aurora-DB-Clusters sollte in Zeiten mit geringem Datenverkehr durchgeführt werden. Verwenden Sie Performance Insights, um diese Zeiträume zu identifizieren und die Wartungsfenster korrekt zu konfigurieren. Weitere Informationen zu Performance Insights finden Sie unter [Überwachen der DB-Auslastung mit Performance Insights in Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PerfInsights.html). Weitere Informationen zu DB-Cluster-Wartungsfenstern finden Sie unter [Anpassen des bevorzugten DB-Cluster-Wartungsfensters](USER_UpgradeDBInstance.Maintenance.md#AdjustingTheMaintenanceWindow.Aurora).
+ Verwenden Sie AWS SDKs diese Unterstützung für exponentiellen Backoff und Jitter als bewährte Methode. Weitere Informationen finden Sie unter [Exponentielles Backoff und Jitter](https://aws.amazon.com/blogs/architecture/exponential-backoff-and-jitter/).

## So führen Sie Upgrades von Nebenversionen durch und wenden Patches an
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 Stabilität der Aurora PostgreSQL-Flotte nicht beeinträchtigen. 

Wenn Sie **Upgrade einer Nebenversion automatisch durchführen** aktivieren, führt Aurora PostgreSQL während Ihres festgelegten Wartungsfensters regelmäßig Upgrades für Ihren DB-Cluster durch. Stellen Sie sicher, dass die Option **Automatisches Nebenversions-Upgrade aktivieren** für alle Instances Ihres Aurora-PostgreSQL-DB-Clusters aktiviert ist. 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](USER_UpgradeDBInstance.Maintenance.md#Aurora.Maintenance.AMVU).

Überprüfen Sie den Wert der Option **auto Upgrade der Nebenversion aktivieren** für all Ihre Aurora PostgreSQL-DB-Cluster, indem Sie den [describe-db-instances](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-instances.html) AWS CLI folgenden Befehl 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 Befehl geht davon aus, 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](USER_UpgradeDBInstance.Maintenance.md#Aurora.Maintenance.AMVU). 

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.\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/images/apg-maintenance-upgrade-minor.png)


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](USER_UpgradeDBInstance.Maintenance.md). 

## Nebenversions-Upgrades und Zero-Downtime-Patching
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\$1-Instance-Klassen | db.t\$1-Instance-Klassen | db.x\$1-Instance-Klassen | db.serverless-Instance-Klasse | 
| --- | --- | --- | --- | --- | 
| 10.21 und höhere Versionen | Ja | Ja | Ja | – | 
| 11.16 und höhere Versionen | Ja | Ja | Ja | – | 
| 11.17 und höhere Versionen | Ja | Ja | Ja | – | 
| 12.11 und höhere Versionen | Ja | Ja | Ja | – | 
| 12.12 und höhere Versionen | Ja | Ja | Ja | – | 
| 13.7 und höhere Versionen | Ja | Ja | Ja | – | 
| 13.8 und höhere Versionen | Ja | Ja | Ja | Ja | 
| 14.3 und höhere Versionen | Ja | Ja | Ja | – | 
| 14.4 und höhere Versionen | Ja | Ja | Ja | – | 
| 14.5 und höhere Versionen | Ja | Ja | Ja | Ja | 
| 15.3 und höhere Versionen | Ja | Ja | Ja | Ja | 
| 16.1 und höhere Versionen | Ja | Ja | Ja | Ja | 

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. 

## Einschränkungen des Patchens ohne Ausfallzeiten
Einschränkungen des Patchens ohne Ausfallzeiten

Die folgenden Einschränkungen gelten für das Patchen ohne Ausfallzeiten:
+ ZDP versucht, die aktuellen Client-Verbindungen zur Aurora PostgreSQL-Writer-Instance während des Aurora-PostgreSQL-Upgrade-Prozesses beizubehalten. 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.
  + TLSv11. Verbindungen werden verwendet. Beginnend mit Aurora PostgreSQL-Versionen nach 16.1, 15.3, 14.8, 13.11, 12.15 und 11.20 wird ZDP mit 3.3-Verbindungen unterstützt. TLSv1
+ ZDP wird in folgenden Fällen nicht unterstützt:
  + Wenn DB-Cluster von Aurora PostgreSQL als Aurora Serverless v1 konfiguriert sind.
  + Während des Upgrades von Aurora-Reader-Instances.
  + Während des Upgrades von Aurora-Reader-Instances, die Teil eines globalen Aurora-Datenbank-Clusters in einer sekundären Region sind.
  + Während Betriebssystem-Patches und Betriebssystem-Upgrades.

## Durchführen eines Upgrades der Aurora-PostgreSQL-Engine auf eine neue Nebenversion
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 in[Sicherstellen der Planstabilität nach einem größeren Versions-Upgrade](AuroraPostgreSQL.Optimize.BestPractice.md#AuroraPostgreSQL.Optimize.BestPractice.MajorVersionUpgrade). 

### Konsole


**So aktualisieren Sie die Engine-Version Ihres Aurora-PostgreSQL-DB-Clusters.**

1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Amazon RDS-Konsole unter [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).

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

1. Wählen Sie **Ändern** aus. Die Seite **DB-Cluster ändern** wird angezeigt.

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

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

1. 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](Aurora.Modifying.md). 

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

### AWS CLI


Um die Engine-Version eines DB-Clusters zu aktualisieren, verwenden Sie den [modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html) 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-versions](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-engine-versions.html)Befehl, 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 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
```

### RDS-API


Verwenden Sie den DBCluster Vorgang [Modify](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html), um die Engine-Version eines DB-Clusters zu aktualisieren. 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 Informationen zu gültigen Engine-Versionen erhalten Sie mit dem Vorgang [DBEngineVersionen beschreiben](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBEngineVersions.html).
+ `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
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](USER_UpgradeDBInstance.PostgreSQL.MajorVersion.md#upgrade-extensions) in [Testen eines Upgrades Ihres Produktions-DB-Clusters auf eine neue Hauptversion](USER_UpgradeDBInstance.PostgreSQL.MajorVersion.md#USER_UpgradeDBInstance.PostgreSQL.MajorVersion.Upgrade.preliminary).

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](AuroraPostgreSQL.Security.md). 

**Anmerkung**  
Hinweise zum Aktualisieren der PostGIS-Erweiterung finden Sie unter [Verwalten von Geodaten mit der PostGIS-Erweiterung](Appendix.PostgreSQL.CommonDBATasks.PostGIS.md) ([Schritt 6: Upgrade der PostGIS-Erweiterung](Appendix.PostgreSQL.CommonDBATasks.PostGIS.md#Appendix.PostgreSQL.CommonDBATasks.PostGIS.Update)).  
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\$1repack installation](https://reorg.github.io/pg_repack/) 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\$1extension](https://www.postgresql.org/docs/current/catalog-pg-extension.html) 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\$1available\$1extension\$1versions](https://www.postgresql.org/docs/current/view-pg-available-extension-versions.html) in dem folgenden Befehl. 

```
SELECT * FROM pg_available_extension_versions;
```

## Alternative blue/green Upgrade-Technik


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, bei dem der alte und der neue Cluster side-by-side ausgeführt werden. Hier replizieren Sie Daten vom alten auf den neuen Cluster, bis der neuen Cluster zur Übernahme bereit ist. Details hierzu finden Sie unter [Verwenden von Amazon Aurora Blue/Green Deployments für Datenbank-Updates](blue-green-deployments.md).

# Verwenden einer Aurora PostgreSQL Long-Term Support (LTS, Langzeit-Support)-Version
Long-Term Support- (LTS, Langzeit-Support) Versionen nutzen

 Jede neue Aurora-PostgreSQL-Version bleibt für eine bestimmte Zeit zum Erstellen oder Aktualisieren eines DB-Clusters verfügbar. Nach diesem Zeitraum müssen Sie alle Cluster aktualisieren, die diese Version verwenden. Sie können Ihren Cluster vor Ablauf des Supportzeitraums manuell aktualisieren, oder Aurora kann ihn automatisch für Sie aktualisieren, wenn die Aurora-PostgreSQL-Version nicht mehr unterstützt wird. 

 Aurora bezeichnet bestimmte Aurora-PostgreSQL-Versionen als „Long-term Support“ (LTS, Langzeitsupport)-Versionen. Datenbank-Cluster, die LTS-Versionen verwenden, können länger dieselbe Version nutzen und weniger Upgradezyklen durchlaufen als Cluster, die Nicht-LTS-Versionen verwenden. LTS-Nebenversionen enthalten nur Bugfixes (über Patch-Versionen) für kritische Stabilitäts- und Sicherheitsprobleme. Eine LTS-Version enthält keine neuen Funktionen, die nach ihrer Einführung veröffentlicht wurden. 

 Einmal im Jahr werden DB-Cluster, die auf einer LTS-Nebenversion ausgeführt werden, auf die neueste Patch-Version der LTS-Version gepatcht. Wir führen diese Patches durch, um sicherzustellen, dass Sie von kumulativen Sicherheits- und Stabilitätsbehebungen profitieren. Wir können eine LTS-Nebenversion häufiger patchen, wenn kritische Bugfixes, z. B. für die Sicherheit, angewendet werden müssen. 

**Anmerkung**  
Um für die Dauer ihres Lebenszyklus auf einer LTS-Nebenversion zu bleiben, stellen Sie sicher, dass Sie das automatische Upgrade der Nebenversion für Ihre DB-Instances deaktivieren. Um zu vermeiden, dass Ihr DB-Cluster automatisch von der LTS-Nebenversion aktualisiert wird, deaktivieren Sie das Kontrollkästchen **Automatische Aktualisierung von Unterversionen aktivieren** für alle DB-Instances in Ihrem Aurora-Cluster.

 Wir empfehlen, dass Sie für die meisten Ihrer Aurora-PostgreSQL-Cluster auf die neueste Version upgraden, anstatt die LTS-Version zu verwenden. Auf diese Weise wird Aurora als Managed verwalteter Service genutzt und Sie erhalten Zugriff auf die neuesten Funktionen und Bugfixes. Die LTS-Releases sind für Cluster mit folgenden Merkmalen gedacht: 
+  Sie können sich, abgesehen von seltenen Fällen, keine Upgrade-Ausfallzeiten Ihrer Aurora-PostgreSQL-Anwendung für kritische Patches leisten. 
+  Der Testzyklus für den Cluster und die zugehörigen Anwendungen dauert bei einer Aktualisierung der Aurora-PostgreSQL-Datenbank-Engine sehr lange. 
+  Die Datenbankversion für Ihren Aurora-PostgreSQL-Cluster enthält alle Funktionen der DB-Engine und Bugfixes, die Ihre Anwendung benötigt. 

 Die aktuellen LTS-Versionen für Aurora PostgreSQL lauten wie folgt: 
+ PostgreSQL 16.8. Es wurde am 07. April 2025 veröffentlicht. Weitere Informationen finden Sie unter [PostgreSQL 16.8](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version168x) in den *Versionshinweisen für* Aurora PostgreSQL. 
+ PostgreSQL 15.10. Es wurde am 27. Dezember 2024 veröffentlicht. Weitere Informationen finden Sie unter [PostgreSQL 15.10](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1510x) in den *Versionshinweisen für* Aurora PostgreSQL. 
+ PostgreSQL 14.6. Es wurde am 20. Januar 2023 veröffentlicht. Weitere Informationen finden Sie unter [PostgreSQL 14.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#AuroraPostgreSQL.Updates.20180305.146X) in den *Versionshinweisen für Aurora PostgreSQL*. 
+ PostgreSQL 13.9. Es wurde am 20. Januar 2023 veröffentlicht. Weitere Informationen finden Sie unter [PostgreSQL 13.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#AuroraPostgreSQL.Updates.20180305.139X) in den *Versionshinweisen für Aurora PostgreSQL*. 
+ PostgreSQL 12.9. Sie wurde am 25. Februar 2022 veröffentlicht. Weitere Informationen finden Sie unter [PostgreSQL 12.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#AuroraPostgreSQL.Updates.20180305.129) in den *Versionshinweisen für Aurora PostgreSQL*. 
+ PostgreSQL 11.9 (Aurora PostgreSQL Version 3.4. Sie wurde am 11. Dezember 2020 veröffentlicht. Weitere Informationen zu dieser Version finden Sie unter [PostgreSQL 11.9, Aurora PostgreSQL Version 3.4](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#AuroraPostgreSQL.Updates.20180305.34) in den *Versionshinweisen für Aurora PostgreSQL*.

Einzelheiten zu Support-Zeitplänen und Veröffentlichungszyklen für die LTS-Versionen finden Sie unter [Veröffentlichungskalender für Aurora PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/aurorapostgresql-release-calendar.html).

Hinweise zum Identifizieren von Aurora- und Datenbank-Engine-Versionen finden Sie unter [Identifizieren der Versionen von Amazon Aurora PostgreSQL](AuroraPostgreSQL.Updates.md#AuroraPostgreSQL.Updates.Versions).