Amazon-Aurora-Versionen - Amazon Aurora

Amazon-Aurora-Versionen

Amazon Aurora verwendet Code wieder und behält die Kompatibilität mit den zugrunde liegenden MySQL- und PostgreSQL-DB-Engines bei. Aurora verfügt jedoch über eigene Versionsnummern, einen eigenen Release-Zyklus, einen eigenen Zeitplan für die Einstellung der Version usw. Im folgenden Abschnitt werden die gemeinsamen Punkte und Unterschiede erläutert. Mithilfe dieser Informationen können Sie entscheiden, welche Version Sie auswählen und wie Sie überprüfen können, welche Funktionen und Fehlerbehebungen in jeder Version verfügbar sind. Es kann Ihnen auch helfen, zu entscheiden, wie oft Sie ein Upgrade durchführen und wie Sie Ihren Upgrade-Prozess planen.

Relationale Datenbanken, die auf Aurora verfügbar sind

Die folgenden relationalen Datenbanken sind auf Aurora verfügbar:

Unterschiede in den Versionsnummern zwischen Community-Datenbanken und Aurora

Jede Amazon-Aurora-Version ist mit einer bestimmten Community-Datenbankversion von MySQL oder PostgreSQL kompatibel. Sie können die Community-Version Ihrer Datenbank mithilfe der version-Funktion und die Aurora-Version mithilfe der aurora_version-Funktion finden.

Folgende Beispiele für Aurora MySQL und Aurora PostgreSQL werden gezeigt.

mysql> select version(); +------------------+ | version() | +------------------+ | 5.7.12 | +------------------+ mysql> select aurora_version(), @@aurora_version; +------------------+------------------+ | aurora_version() | @@aurora_version | +------------------+------------------+ | 2.08.1 | 2.08.1 | +------------------+------------------+
postgres=> select version(); ----------------------------------------------------------------------------- PostgreSQL 11.7 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.9.3, 64-bit (1 row) postgres=> select aurora_version(); aurora_version ---------------- 3.2.2

Weitere Informationen erhalten Sie unter Überprüfen von Aurora MySQL-Versionen mit SQL und Identifizieren der Versionen von Amazon Aurora PostgreSQL.

Amazon-Aurora-Hauptversionen

Aurora-Versionen verwenden das Schema major.minor.patch. Eine Aurora-Hauptversion bezieht sich auf die MySQL- oder PostgreSQL-Community-Hauptversion, mit der Aurora kompatibel ist. Das folgende Beispiel zeigt das Mapping zwischen Community-MySQL- und PostgreSQL-Versionen und den entsprechenden Aurora-Versionen.

Community-Hauptversion Aurora-Hauptversion
MySQL 5.6 Aurora MySQL 1
MySQL 5.7 Aurora MySQL 2
MySQL 8.0 Aurora MySQL 3
PostgreSQL 9.6 (veraltet) Aurora PostgreSQL 1
PostgreSQL 10 Aurora PostgreSQL 2. Gilt nur für PostgreSQL 10.17 und ältere Versionen. Für Version 10.18 und höhere Versionen ist die Aurora-Version die gleiche wie die Hauptversion.Nebenversion der PostgreSQL-Community-Version, wobei eine dritte Ziffer an der Position patch steht.
PostgreSQL 11 Aurora PostgreSQL 3. Gilt nur für PostgreSQL 11.12 und ältere Versionen. Für Version 11.13 und höhere Versionen ist die Aurora-Version die gleiche wie die Hauptversion.Nebenversion der PostgreSQL-Community-Version, wobei eine dritte Ziffer an der Position patch steht.
PostgreSQL 12 Aurora PostgreSQL 4. Gilt nur für PostgreSQL 12.7 und ältere Versionen. Für Version 12.8 und höhere Versionen ist die Aurora-Version die gleiche wie die Hauptversion.Nebenversion der PostgreSQL-Community-Version, wobei eine dritte Ziffer an der Position patch steht.
PostgreSQL 13 Aurora PostgreSQL 4. Gilt nur für PostgreSQL 13.2 und ältere Versionen. Für Version 13.3 und höhere Versionen ist die Aurora-Version die gleiche wie die Hauptversion.Nebenversion der PostgreSQL-Community-Version, wobei eine dritte Ziffer an der Position patch steht.
PostgreSQL 14 Aurora PostgreSQL 14.3. Die Aurora-Version ist die gleiche wie die Hauptversion.Nebenversion der PostgreSQL-Community-Version, wobei eine dritte Ziffer an der Patch-Stelle steht, sofern Patches für Aurora veröffentlicht werden.

Amazon-Aurora-Nebenversionen

Aurora-Versionen verwenden das Schema major.minor.patch. Eine Aurora-Nebenversion bietet inkrementelle Community- und Aurora-spezifische Verbesserungen des Services, zum Beispiel neue Funktionen und Fehlerkorrekturen.

Aurora-Nebenversionen werden immer einer bestimmten Community-Version zugeordnet. Einige Community-Versionen verfügen jedoch möglicherweise nicht über ein Aurora-Äquivalent.

Amazon-Aurora-Patchversionen

Aurora-Versionen verwenden das Schema major.minor.patch. Eine Aurora-Patchversion enthält wichtige Fehlerkorrekturen, die einer Nebenversion nach ihrer ersten Veröffentlichung hinzugefügt wurden (z. B. Aurora MySQL 2.04.0, 2.04.1, ..., 2.04.9). Während jede neue Nebenversion neue Aurora-Funktionen bietet, werden neue Patch-Versionen innerhalb einer bestimmten Nebenversion hauptsächlich verwendet, um wichtige Probleme zu beheben.

Weitere Informationen zu Patch-Vorgängen finden Sie unter Warten eines Amazon Aurora-DB-Clusters.

Erfahren Sie, was in jeder Amazon-Aurora-Version neu ist

Jede neue Aurora-Version enthält Versionshinweise, in denen die neuen Funktionen, Korrekturen, anderen Verbesserungen usw. aufgeführt sind, die für jede Version gelten.

Versionshinweise für Aurora MySQL finden Sie unter Versionshinweise für Aurora MySQL. Versionshinweise für Aurora PostgreSQL finden Sie unter Versionshinweise für Aurora PostgreSQL.

Angeben der Amazon-Aurora-Datenbankversion für Ihren Datenbank-Cluster

Sie können jede derzeit verfügbare Version (Haupt- und Nebenversion) angeben, wenn Sie einen neuen DB-Cluster erstellen, indem Sie die Operation Datenbank erstellen in der AWS Management Console-, der AWS CLI-, oder der CreateDBCluster-API-Operation verwenden. Nicht jede Aurora Datenbankversion ist in jeder AWS-Region verfügbar.

Informationen zum Erstellen von Aurora-Clustern finden Sie unter Erstellen eines Amazon Aurora-DB Clusters. Informationen zum Ändern der Version eines vorhandenen Aurora-Clusters finden Sie unter Ändern eines Amazon Aurora-DB-Clusters.

Standard-Amazon-Aurora-Versionen

Wenn eine neue Aurora-Nebenversion im Vergleich zu einer vorherigen signifikante Verbesserungen enthält, wird sie als Standardversion für neue DB-Cluster markiert. In der Regel veröffentlichen wir zwei Standardversionen für jede Hauptversion pro Jahr.

Wir empfehlen, dass Sie Ihr DB-Cluster auf die aktuellste Standard-Nebenversion aktualisieren, da diese Version die neuesten Sicherheits- und Funktionskorrekturen enthält.

Automatische Unterversion-Upgrades

Sie können mit Aurora-Nebenversionen auf dem Laufenden bleiben, indem Sie für jede DB-Instance im Aurora-Cluster das automatische Upgrade der Nebenversion aktivieren. Aurora führt das automatische Upgrade nur durch, wenn alle DB-Instances in Ihrem Cluster diese Einstellung aktiviert haben. Automatische Nebenversions-Upgrades werden auf die standardmäßige Nebenversion durchgeführt.

Normalerweise planen wir zweimal im Jahr automatische Upgrades für DB-Cluster, bei denen die Einstellung Automatisches Upgrade der Nebenversion auf Yes gesetzt ist. Diese Upgrades werden während des Wartungsfensters gestartet, das Sie für den Cluster angeben. Weitere Informationen finden Sie unter Aktivieren von automatischen Upgrades zwischen Aurora MySQL-Nebenversionen und So führen Sie Upgrades von Nebenversionen durch und wenden Patches an.

Automatische Upgrades von Nebenversionen werden im Voraus über ein Amazon-RDS-DB-Clusterereignis mit der Kategorie maintenance und der ID RDS-EVENT-0156 kommuniziert. Weitere Informationen finden Sie unter Amazon RDS-Ereigniskategorien und -Ereignismeldungen.

Wie lange bleiben Amazon-Aurora-Hauptversionen verfügbar

Die Hauptversionen von Amazon Aurora stehen mindestens bis zum Ende des Lebenszyklus der Community für die entsprechende Community-Version zur Verfügung. Sie können die folgenden Daten verwenden, um Ihre Test- und Upgrade-Zyklen zu planen. Diese Daten stellen das früheste Datum dar, an dem ein Upgrade auf eine neuere Version erforderlich sein könnte. Wenn Amazon die Unterstützung für eine Aurora-Version länger als ursprünglich geplant erweitert, planen wir, diese Tabelle zu aktualisieren, um das spätere Datum widerzuspiegeln.

Datenbank-Community-Version Aurora-Version Voraussichtliches Datum für das Upgrade auf eine neuere Version
MySQL 5.6 1 28. Februar 2023, 00:00:00 UTC
MySQL 5.7 2 31. Oktober 2024
MySQL 8.0 3
PostgreSQL 9.6 (veraltet) 1 31. Januar 2022
PostgreSQL 10 Variiert je nach Nebenversion der Aurora-PostgreSQL-Version. Weitere Informationen finden Sie unter Amazon-Aurora-Hauptversionen. 31. Januar 2023
PostgreSQL 11 31. Januar 2024
PostgreSQL 12 28. Februar 2025
PostgreSQL 13 31. Januar 2026
PostgreSQL 14Die Aurora-Version ist die gleiche wie die Hauptversion.Nebenversion der PostgreSQL-Community-Version, wobei eine dritte Ziffer an der Patch-Stelle steht.31. Januar 2027

Bevor wir Sie bitten, auf eine neuere Hauptversion zu aktualisieren und Ihnen bei der Planung zu helfen, geben wir Ihnen mindestens zwölf Monate im Voraus eine Erinnerung. Wir tun dies, um den detaillierten Upgrade-Prozess zu kommunizieren. Details umfassen das Timing bestimmter Meilensteine, die Auswirkungen auf Ihre DB-Cluster und die von Ihnen empfohlenen Aktionen. Es wird immer empfohlen, Ihre Anwendungen mit neuen Datenbankversionen gründlich zu testen, bevor Sie ein Upgrade der Hauptversion durchführen.

Nach diesem Zeitraum von 12 Monaten kann ein automatisches Upgrade auf die nachfolgende Hauptversion auf alle Datenbank-Cluster angewendet werden, auf denen die ältere Version ausgeführt wird. Falls zutreffend, wird das Upgrade während der geplanten Wartungsfenster gestartet.

Wie oft werden Amazon-Aurora-Nebenversionen veröffentlicht

Im Allgemeinen werden Amazon-Aurora-Nebenversionen vierteljährlich veröffentlicht. Der Release-Zeitplan kann variieren, um zusätzliche Funktionen oder Korrekturen aufzunehmen.

Langzeit-Support für ausgewählte Amazon-Aurora-Nebenversionen

Für jede Aurora-Hauptversion werden bestimmte Nebenversionen als LTS-Versionen (Long-Term-Support, Langzeit-Support) bezeichnet und für mindestens drei Jahre zur Verfügung gestellt. Das heißt, mindestens eine Nebenversion pro Hauptversion wird länger als die typischen 12 Monate zur Verfügung gestellt. Wir erinnern in der Regel sechs Monate vor Ablauf dieser Frist daran. Wir tun dies, um den detaillierten Upgrade-Prozess zu kommunizieren. Details umfassen das Timing bestimmter Meilensteine, die Auswirkungen auf Ihre DB-Cluster und die von Ihnen empfohlenen Aktionen.

LTS-Nebenversionen enthalten nur wichtige Fehlerkorrekturen (über Patch-Versionen). 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 Fehlerbehebungen, 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, legen Sie die Option Auto minor version upgrade (Automatisches Nebenversion-Upgrade) für alle DB-Instances in Ihrem Aurora-Cluster auf No fest.

Die Versionsnummern aller Aurora LTS-Versionen finden Sie unter Aurora MySQL Long-Term Support- (LTS, Langzeit-Support) Versionen und Aurora PostgreSQL Long-Term Support- (LTS, Langzeit-Support) Versionen.

Manuelles Steuern, ob und wann Ihr Datenbank-Cluster auf neue Versionen aktualisiert wird

Automatische Nebenversions-Upgrades werden auf die standardmäßige Nebenversion durchgeführt. Normalerweise planen wir zweimal im Jahr automatische Upgrades für DB-Cluster, bei denen die Einstellung Automatisches Upgrade der Nebenversion auf Yes gesetzt ist. Diese Upgrades werden während kundenspezifischer Wartungsfenster gestartet. Wenn Sie automatische Nebenversions-Upgrades deaktivieren möchten, setzen Sie Automatisches Nebenversions-Upgrade auf einer beliebigen DB-Instance innerhalb eines Aurora-Clusters auf No. Aurora führt nur dann ein automatisches Nebenversions-Upgrade durch, wenn alle DB-Instances in Ihrem Cluster die Einstellung aktiviert haben.

Da Upgrades von Hauptversionen ein gewisses Kompatibilitätsrisiko beinhalten, werden sie nicht automatisch ausgeführt. Sie müssen diese initiieren, außer im Fall eines Hauptversions-Upgrades aufgrund der Einstellung, wie zuvor erläutert. Es wird immer empfohlen, Ihre Anwendungen mit neuen Datenbankversionen gründlich zu testen, bevor Sie ein Upgrade der Hauptversion durchführen.

Weitere Informationen zum Aktualisieren eines DB-Clusters auf eine neue Aurora-Hauptversion finden Sie unter Upgrade von Amazon Aurora MySQL-DB-Clustern und Aktualisieren einer PostgreSQL-DB-Engine für Aurora PostgreSQL.

Erforderliche Amazon-Aurora-Upgrades

Bei bestimmten kritischen Fehlerbehebungen führen wir möglicherweise ein verwaltetes Upgrade auf eine neuere Patch-Stufe innerhalb derselben Nebenversion durch. Diese erforderlichen Upgrades erfolgen auch dann, wenn das automatische Upgrade der Nebenversion deaktiviert ist. Zuvor kommunizieren wir den detaillierten Upgrade-Prozess. Details umfassen das Timing bestimmter Meilensteine, die Auswirkungen auf Ihre DB-Cluster und die von Ihnen empfohlenen Aktionen. Solche verwalteten Upgrades werden automatisch durchgeführt. Jedes Upgrade wird innerhalb des Wartungsfensters des Clusters gestartet.

Testen Ihres DB-Clusters mit einer neuen Aurora-Version vor dem Upgrade

Sie können den Upgrade-Prozess und die Funktionsweise der neuen Version mit Ihrer Anwendung und Ihrer Workload testen. Verwenden Sie eine der folgenden Methoden:

  • Klonen Sie Ihren Cluster mit der Funktion zum schnellen Klonen von Amazon-Aurora-Datenbanken. Führen Sie das Upgrade und alle Tests nach dem Upgrade auf dem neuen Cluster durch.

  • Wiederherstellung aus einem Cluster-Snapshot, um einen neuen Aurora-Cluster zu erstellen. Sie können einen Cluster-Snapshot selbst aus einem vorhandenen Aurora-Cluster erstellen. Aurora erstellt außerdem automatisch periodische Snapshots für jeden deiner Cluster. Anschließend können Sie ein Versionsupdate für den neuen Cluster initiieren. Sie können mit der aktualisierten Kopie des Clusters experimentieren, bevor Sie entscheiden, ob Sie den ursprünglichen Cluster aktualisieren möchten.

Weitere Informationen zu diesen Methoden zum Erstellen neuer Cluster zum Testen finden Sie unter Klonen eines Volumes für einen Amazon-Aurora-DB-Cluster und Erstellen eines DB-Cluster-Snapshots.