Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
# Upgrade der Nebenversion oder der Patch-Ebene eines Aurora MySQL-DB-Clusters
Sie können die folgenden Methoden verwenden, um die Nebenversion eines DB-Clusters zu aktualisieren oder einen DB-Cluster zu patchen:
+ [Upgrade von Aurora MySQL durch Ändern der Engine-Version](AuroraMySQL.Updates.Patching.ModifyEngineVersion.md) (für Aurora-MySQL-Version 2) und 3
+ [Aktivieren von automatischen Upgrades zwischen Aurora MySQL-Nebenversionen](AuroraMySQL.Updates.AMVU.md)
Informationen dazu, wie Patches ohne Ausfallzeiten Unterbrechungen während des Upgrade-Vorgangs reduzieren können, finden Sie unter [Verwendung von Zero-Downtime-Patching (Patchen ohne Ausfallzeiten)](AuroraMySQL.Updates.ZDP.md).
Informationen zum Durchführen eines Nebenversions-Upgrades für Ihren DB-Cluster von Aurora MySQL finden Sie in den folgenden Themen.
**Topics**
+ [Vor dem Durchführen eines Nebenversions-Upgrades](#USER_UpgradeDBInstance.PostgreSQL.BeforeMinor)
+ [Vorabprüfungen für Nebenversions-Upgrades von Aurora MySQL](#AuroraMySQL.minor-upgrade-prechecks)
+ [Upgrade von Aurora MySQL durch Ändern der Engine-Version](AuroraMySQL.Updates.Patching.ModifyEngineVersion.md)
+ [Aktivieren von automatischen Upgrades zwischen Aurora MySQL-Nebenversionen](AuroraMySQL.Updates.AMVU.md)
+ [Verwendung von Zero-Downtime-Patching (Patchen ohne Ausfallzeiten)](AuroraMySQL.Updates.ZDP.md)
+ [Alternative Upgrade-Technik blue/green](#AuroraMySQL.UpgradingMinor.BlueGreen)
## 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/).
## Vorabprüfungen für Nebenversions-Upgrades von Aurora MySQL
Wenn Sie ein Nebenversions-Upgrade starten, führt Amazon Aurora automatisch Vorabprüfungen durch.
Diese Vorabprüfungen müssen durchgeführt werden. Sie können nicht ausgelassen werden. Die Vorabprüfungen bieten folgende Vorteile:
+ Sie können ungeplante Ausfallzeiten während des Upgrades vermeiden.
+ Wenn es Inkompatibilitäten gibt, verhindert Amazon Aurora das Upgrade und stellt Ihnen ein Protokoll mit Informationen zu den Inkompatibilitäten bereit. Sie können das Protokoll für die Vorbereitung Ihrer Datenbank auf das Upgrade verwenden, indem Sie die Inkompatibilitäten reduzieren. Detaillierte Informationen zum Entfernen von Inkompatibilitäten finden Sie unter [Vorbereiten Ihrer Installation auf ein Upgrade](https://dev.mysql.com/doc/refman/8.0/en/upgrade-prerequisites.html) in der MySQL-Dokumentation.
Die Vorabprüfungen werden ausgeführt, bevor die DB-Instance aufgrund des Upgrades angehalten wird. Sie verursachen also keine Ausfallzeiten. Wird während der Vorabprüfungen eine Inkompatibilität entdeckt, bricht Aurora automatisch das Upgrade ab, ehe die DB-Instance angehalten wird. Aurora generiert auch ein Ereignis für die Inkompatibilität. Weitere Informationen über Amazon-Aurora-Ereignisse finden Sie unter [Arbeiten mit Amazon-RDS-Ereignisbenachrichtigungen](USER_Events.md).
Aurora zeichnet detaillierte Informationen zu allen Inkompatibilitäten in der Protokolldatei `PrePatchCompatibility.log` auf. In den meisten Fällen enthalten die Protokolleinträge einen Link zur MySQL-Dokumentation mit Informationen zur Lösung des Inkompatibilitätsproblems. Weitere Informationen zum Anzeigen von Protokolldateien finden Sie unter [Anzeigen und Auflisten von Datenbank-Protokolldateien](USER_LogAccess.Procedural.Viewing.md).
Aufgrund der Art der Vorabprüfungen werden die Objekte in Ihrer Datenbank geprüft. Diese Analyse verbraucht Ressourcen und verlängert die Zeit, die für die Durchführung des Upgrades benötigt wird.
# Upgrade von Aurora MySQL durch Ändern der Engine-Version
Beim Upgrade der Nebenversion eines DB-Clusters von Aurora MySQL werden zusätzliche Korrekturen und neue Funktionen auf einen vorhandenen Cluster angewendet.
Diese Art von Upgrade gilt für Aurora-MySQL-Cluster, bei denen die ursprüngliche Version und die aktualisierte Version dieselbe Aurora-MySQL-Hauptversion haben, entweder 2 oder 3. Der Prozess ist schnell und unkompliziert, da er keine Konvertierung für die Aurora-MySQL-Metadaten oder Reorganisation Ihrer Tabellendaten erfordert.
Sie führen diese Art von Upgrade durch, indem Sie die Engine-Version des DB-Clusters mithilfe der AWS-Managementkonsole, AWS CLI oder der RDS-API ändern. Wenn beispielsweise in Ihrem Cluster Aurora MySQL 3.x ausgeführt wird, wählen Sie eine höhere 3.x-Version.
Wenn Sie ein Nebenversions-Upgrade für eine Aurora Global Database durchführen, aktualisieren Sie alle sekundären Cluster, bevor Sie den primären Cluster aktualisieren.
**Anmerkung**
Gehen Sie wie folgt vor, um ein Unterversion-Upgrade auf Aurora-MySQL-Version 3.04.\$1 oder höher bzw. Version 2.12\$1 durchzuführen:
Entfernen Sie alle sekundären Regionen aus dem globalen Cluster. Führen Sie die Schritte unter au [Entfernen eines Clusters aus einer Amazon Aurora Global Database](aurora-global-database-detaching.md).
Aktualisieren Sie die Engine-Version der primären Region auf Version 3.04.\$1 oder höher bzw. Version 2.12.\$1, falls zutreffend. Führen Sie die Schritte unter au [To modify the engine version of a DB cluster](#modify-db-cluster-engine-version).
Fügen Sie dem globalen Cluster sekundäre Regionen hinzu. Führen Sie die Schritte unter au [Hinzufügen einer AWS-Region zu einer globalen Amazon-Aurora-Datenbank](aurora-global-database-attaching.md).
**So ändern Sie die Engine-Version eines DB-Clusters**:
+ **Über die Konsole** – Ändern Sie die Eigenschaften Ihres Clusters. Ändern Sie im Fenster **DB-Cluster ändern** die Aurora-MySQL-Engine-Version im Feld **DB-Engine-Version**. Wenn Sie mit dem allgemeinen Verfahren zum Ändern eines Clusters nicht vertraut sind, folgen Sie den Anweisungen unter [Ändern des DB-Clusters über die Konsole, die CLI und die API](Aurora.Modifying.md#Aurora.Modifying.Cluster).
+ **Über die AWS CLI** Rufen Sie den AWS CLI-Befehl [modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html) auf und geben Sie den Namen Ihres DB-Clusters für die Option `--db-cluster-identifier` sowie die Engine-Version für die Option `--engine-version` an.
Um beispielsweise auf Aurora-MySQL-Version 3.04.1 zu aktualisieren, legen Sie die Option `--engine-version` auf `8.0.mysql_aurora.3.04.1` fest. Geben Sie die Option `--apply-immediately` an, um die Engine-Version für Ihren DB-Cluster sofort zu aktualisieren.
+ **Über die RDS-API** Rufen Sie die API-Operation [ModifyDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html) auf und geben Sie den Namen Ihres DB-Clusters für den Parameter `DBClusterIdentifier` sowie die Engine-Version für den Parameter `EngineVersion` an. Legen Sie den Parameter `ApplyImmediately` auf `true` fest, um die Engine-Version für Ihren DB-Cluster sofort zu aktualisieren.
# Aktivieren von automatischen Upgrades zwischen Aurora MySQL-Nebenversionen
Für einen DB-Cluster von Amazon Aurora MySQL können Sie angeben, dass Aurora den DB-Cluster automatisch auf neue Nebenversionen aktualisiert. Sie tun dies, indem Sie die `AutoMinorVersionUpgrade`-Eigenschaft (**Automatisches Unterversion-Upgrade** in der AWS-Managementkonsole) des DB-Clusters festlegen.
Automatische Aktualisierungen erfolgen während des Wartungsfensters. Wenn die einzelnen DB-Instances im DB-Cluster andere Wartungsfenster haben als das Cluster-Wartungsfenster, hat das Cluster-Wartungsfenster Vorrang.
Das automatische Nebenversions-Upgrade gilt nicht für die folgenden Aurora MySQL-Clustertypen:
+ Cluster, die Teil einer globalen Aurora-Datenbank sind
+ Cluster, die über regionsübergreifende Replikate verfügen
Die Ausfalldauer hängt vom Workload, der Cluster-Größe, der Menge der binären Protokolldaten und davon ab, ob Aurora die Funktion „Patching ohne Ausfallzeiten“ (Zero Downtime Patching, ZDP) verwenden kann. Aurora startet den Datenbankcluster neu, sodass Sie möglicherweise eine kurze Zeit nicht verfügbar sind, bevor Sie Ihren Cluster wieder verwenden. Insbesondere wirkt sich die Menge der Binärprotokolldaten auf die Wiederherstellungszeit aus. Die DB-Instance verarbeitet die binären Protokolldaten während der Wiederherstellung. Somit erhöht eine hohe Menge an binären Protokolldaten die Wiederherstellungszeit.
**Anmerkung**
Aurora führt automatische Upgrades nur durch, wenn alle DB-Instances in Ihrem DB-Cluster die `AutoMinorVersionUpgrade`-Einstellung aktiviert haben. Informationen zum Festlegen der Einstellung und zu deren Funktionsweise, 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).
Wenn dann ein Upgrade-Pfad für die Instances des DB-Clusters auf eine DB-Engine-Nebenversion existiert, bei der `AutoUpgrade` auf „true“ gesetzt ist, wird das Upgrade durchgeführt. Die `AutoUpgrade`-Einstellung ist dynamisch und wird von RDS festgelegt.
Automatische Nebenversions-Upgrades werden auf die standardmäßige Nebenversion durchgeführt.
Sie können einen CLI-Befehl wie den folgenden verwenden, um den Status der Einstellung `AutoMinorVersionUpgrade` für alle DB-Instances in Ihren Aurora-MySQL-Clustern zu überprüfen.
```
aws rds describe-db-instances \
--query '*[].{DBClusterIdentifier:DBClusterIdentifier,DBInstanceIdentifier:DBInstanceIdentifier,AutoMinorVersionUpgrade:AutoMinorVersionUpgrade}'
```
Die Ausgabe dieses Befehls sieht etwa so aus:
```
[
{
"DBInstanceIdentifier": "db-t2-medium-instance",
"DBClusterIdentifier": "cluster-57-2020-06-03-6411",
"AutoMinorVersionUpgrade": true
},
{
"DBInstanceIdentifier": "db-t2-small-original-size",
"DBClusterIdentifier": "cluster-57-2020-06-03-6411",
"AutoMinorVersionUpgrade": false
},
{
"DBInstanceIdentifier": "instance-2020-05-01-2332",
"DBClusterIdentifier": "cluster-57-2020-05-01-4615",
"AutoMinorVersionUpgrade": true
},
... output omitted ...
```
In diesem Beispiel ist die Einstellung **Automatisches Nebenversions-Upgrade aktivieren** für den DB-Cluster `cluster-57-2020-06-03-6411` deaktiviert, da sie für eine der DB-Instances im Cluster deaktiviert ist.
# Verwendung von Zero-Downtime-Patching (Patchen ohne Ausfallzeiten)
Das Durchführen von Upgrades für Aurora MySQL DB-Cluster beinhaltet die Möglichkeit eines Ausfalls, wenn die Datenbank heruntergefahren wird und während sie aktualisiert wird. Wenn Sie das Upgrade starten, während die Datenbank ausgelastet ist, verlieren Sie standardmäßig 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.
Beim Feature des Patchens ohne Ausfallzeiten (ZDP – Zero-Downtime Patching) wird versucht, Client-Verbindungen auf Best-Effort-Basis vor der Aurora MySQL-Aktualisierung zu bewahren. Wenn das ZDP erfolgreich abgeschlossen wird, werden Anwendungssitzungen bewahrt und die Datenbank-Engine wird während der laufenden Aktualisierung neu gestartet. Der Neustart der Datenbank-Engine kann zu einem Abfall des Durchsatzes von eingen Sekunden bis 1 Minute führen.
ZDP gilt nicht für Folgendes:
+ Patches und Upgrades für das Betriebssystem
+ Hauptversions-Upgrades
ZDP ist für alle unterstützten Aurora-MySQL-Versionen und DB-Instance-Klassen verfügbar.
ZDP wird für Aurora Serverless v1- oder globale Aurora-Datenbanken nicht unterstützt.
**Anmerkung**
Wir empfehlen, die T-DB-Instance-Klassen nur für Entwicklungs- und Testserver oder andere Nicht-Produktionsserver zu verwenden. Weitere Einzelheiten zu den T-Instance-Klassen finden Sie unter [Verwendung von T-Instance-Klassen für Entwicklung und Tests](AuroraMySQL.BestPractices.Performance.md#AuroraMySQL.BestPractices.T2Medium).
Sie können Metriken wichtiger Attribute während des ZDP im MySQL-Fehlerprotokoll sehen. Sie können auch Informationen darüber sehen, wann Aurora MySQL ZDP verwendet oder nicht verwendet und zwar auf der Seite **Ereignisse** der AWS-Managementkonsole.
In Aurora MySQL kann Aurora einen Patch ohne Ausfallzeit ausführen, unabhängig davon, ob die binäre Protokollreplikation aktiviert ist. Wenn die binäre Protokollreplikation aktiviert ist, löscht Aurora MySQL während eines ZDP-Vorgangs automatisch die Verbindung zum Binärprotokollziel. Aurora MySQL stellt automatisch eine Verbindung zum binlog-Ziel her und setzt die Replikation fort, nachdem der Neustart abgeschlossen ist.
Das ZDP arbeitet auch in Kombination mit den Neustartverbesserungen in Aurora MySQL. Durch das Patchen der Writer-DB-Instance werden die Leser automatisch gleichzeitig gepatcht. Aurora stellt nach dem Ausführen des Patches die Verbindungen sowohl auf den Writer- als auch der Reader-DB-Instances wieder
ZDP kann unter den folgenden Bedingungen möglicherweise nicht erfolgreich abgeschlossen werden:
+ Wenn langandauernde Abfragen oder Transaktionen ausgeführt werden. Wenn Aurora in diesem Fall ZDP durchführen kann, werden alle offenen Transaktionen abgebrochen, aber ihre Verbindungen beibehalten.
+ Es werden temporäre Tabellen, Benutzer- oder Tabellensperren verwendet, beispielsweise während Anweisungen für die Datendefinitionssprache (DDL) ausgeführt werden. Aurora trennt diese Verbindungen.
+ Wenn ausstehende Parameteränderungen vorhanden sind.
Wenn sich kein passendes Zeitfenster für die Durchführung von ZDP finden lässt, weil eine dieser Bedingungen vorliegt, wird das Patchen im normalen Modus ausgeführt.
Obwohl Verbindungen nach einem erfolgreichen ZDP-Vorgang intakt bleiben, werden einige Variablen und Funktionen neu initialisiert. Die folgenden Arten von Informationen werden durch einen Neustart, der durch Patchen ohne Ausfallzeiten verursacht wird, nicht beibehalten:
+ Globale Variablen Aurora stellt Sitzungsvariablen wieder her, stellt jedoch nach dem Neustart keine globalen Variablen wieder her.
+ Statusvariablen. Insbesondere wird der vom Engine-Status gemeldete Betriebszeit-Wert nach einem Neustart zurückgesetzt, der die ZDR- oder ZDP-Mechanismen verwendet.
+ `LAST_INSERT_ID`.
+ In-Memory-`auto_increment`-Status für Tabellen. Der Status des automatischen In-Memory-Inkrements wird neu initialisiert. Weitere Informationen zu automatischen Inkrementwerten finden Sie im[ MySQL-Referenzhandbuch](https://dev.mysql.com/doc/refman/5.7/en/innodb-auto-increment-handling.html#innodb-auto-increment-initialization).
+ Diagnoseinformationen aus `INFORMATION_SCHEMA`- und `PERFORMANCE_SCHEMA`-Tabellen. Diese Diagnoseinformationen erscheinen auch in der Ausgabe von Befehlen wie `SHOW PROFILE` und `SHOW PROFILES`.
Die folgenden Aktivitäten im Zusammenhang mit einem Neustart ohne Ausfallzeiten werden auf der Seite ** Ereignisse** gemeldet:
+ Es wird versucht, die Datenbank ohne Ausfallzeiten zu aktualisieren.
+ Der Versuch, die Datenbank ohne Ausfallzeiten zu aktualisieren, ist beendet. Die Veranstaltung berichtet, wie lange der Prozess gedauert hat. Das Ereignis meldet auch, wie viele Verbindungen während des Neustarts beibehalten wurden und wie viele Verbindungen gelöscht wurden. Sie können das Datenbankfehlerprotokoll einsehen, um weitere Details darüber zu erfahren, was während des Neustarts passiert ist.
## Alternative Upgrade-Technik blue/green
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).