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.
# Warten eines Amazon Aurora-DB-Clusters
Amazon RDS führt in regelmäßigen Abständen Wartungsarbeiten an Amazon-RDS-Ressourcen durch. In den folgenden Themen werden diese Wartungsaktionen und ihre Anwendung beschrieben.
## Übersicht über Wartungsupdates für DB-Cluster
Die Wartung beinhaltet in den meisten Fällen Aktualisierungen der folgenden Ressourcen in Ihrem DB-Cluster:
+ Zugrundeliegende Hardware
+ Zugrundeliegendes Betriebssystem
+ Datenbank-Engine-Version
Häufig werden Betriebssystemupdates wegen Sicherheitsproblemen herausgegeben. Wir empfehlen, sie so schnell wie möglich zu installieren. Weitere Informationen über unterstützte Betriebssystemupdates finden Sie unter [Betriebssystemupdates für Aurora-DB-Cluster](#Aurora_OS_updates).
**Topics**
+ [Offline-Ressourcen während Wartungsupdates](#USER_UpgradeDBInstance.Maintenance.Overview.offline)
+ [Aufgeschobene Änderungen der DB-Instance und des DB-Clusters](#USER_UpgradeDBInstance.Maintenance.Overview.Deferred)
+ [Eventuelle Konsistenz für die API DescribePendingMaintenanceActions](#USER_UpgradeDBInstance.Maintenance.Overview.eventual-consistency)
### Offline-Ressourcen während Wartungsupdates
Einige Wartungselemente erfordern, dass Amazon RDS Ihren DB-Cluster für kurze Zeit in den Offlinebetrieb versetzt. Zu den Wartungselementen, für die eine Ressource offline sein muss, gehört z. B. das Ausführen erforderlicher Patches für das Betriebssystem oder die Datenbank. Das erforderliche Patching wird automatisch und nur für Patches eingeplant, welche die Sicherheit und Instance-Zuverlässigkeit betreffen. Solche Patches treten selten auf, in der Regel einmal alle paar Monate. Es ist selten mehr als ein Bruchteil Ihres Wartungsfensters dafür erforderlich.
### Aufgeschobene Änderungen der DB-Instance und des DB-Clusters
Aufgeschobene DB-Cluster- und DB-Instance-Änderungen, die nicht sofort zur Anwendung kommen sollen, werden während des Wartungszeitraums umgesetzt. Sie können beispielsweise wählen, DB-Instance-Klassen oder Cluster- oder DB-Parametergruppen während des Wartungsfensters zu ändern. Solche Änderungen, die Sie mit der Einstellung für **ausstehenden Neustart** angeben, werden nicht in der Liste der **ausstehenden Wartungsarbeiten** angezeigt. Informationen über das Ändern eines DB-Clusters finden Sie unter [Ändern eines Amazon Aurora-DB-Clusters](Aurora.Modifying.md).
Um die Änderungen zu sehen, die für das nächste Wartungsfenster noch ausstehen, verwenden Sie den [describe-db-clusters](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/rds/describe-db-clusters.html) AWS CLI Befehl und überprüfen Sie das `PendingModifiedValues` Feld.
### Eventuelle Konsistenz für die API DescribePendingMaintenanceActions
Die `DescribePendingMaintenanceActions`-API von Amazon RDS folgt einem eventuellen Konsistenzmodell. Dies bedeutet, dass das Ergebnis des `DescribePendingMaintenanceActions`-Befehls möglicherweise nicht sofort für alle nachfolgenden RDS-Befehle, die Sie ausführen, sichtbar ist. Denken Sie daran, wenn Sie `DescribePendingMaintenanceActions` unmittelbar nach der Verwendung eines vorherigen API-Befehls verwenden.
Eine letztendliche Konsistenz kann sich auf die Art und Weise auswirken, wie Sie Ihre Wartungsupdates verwaltet haben. Wenn Sie beispielsweise den `ApplyPendingMaintenanceActions`-Befehl ausführen, um die Version der Datenbank-Engine für eine einen DB-Cluster zu aktualisieren, wird dieser irgendwann für `DescribePendingMaintenanceActions` sichtbar sein. In diesem Szenario zeigt `DescribePendingMaintenanceActions` möglicherweise, dass die Wartungsaktion nicht angewendet wurde, obwohl dies der Fall ist.
Gehen Sie wie folgt vor, um die letztendliche Datenkonsistenz zu verwalten:
+ Bestätigen Sie den Status Ihrer , bevor Sie einen Befehl ausführen, um ihn zu ändern. Führen Sie den entsprechenden Befehl `DescribePendingMaintenanceActions` mit einem exponentiellen Backoff-Algorithmus aus, um sicherzustellen, dass Sie genügend Zeit für die Ausbreitung des vorherigen Befehls im System einplanen. Führen Sie dazu den Befehl `DescribePendingMaintenanceActions` wiederholt aus, wobei Sie mit einer Wartezeit von einigen Sekunden beginnen und die Wartezeit schrittweise auf bis zu fünf Minuten erhöhen.
+ Fügen Sie Wartezeiten zwischen aufeinanderfolgenden Befehlen hinzu, auch wenn der Befehl `DescribePendingMaintenanceActions` eine genaue Antwort zurückgibt. Wenden Sie einen exponentiellen Backoff-Algorithmus an, der mit einer Wartezeit von einigen Sekunden beginnt, und erhöhen Sie die Wartezeit schrittweise auf etwa fünf Minuten.
## Anzeigen ausstehender Wartungs-Updates
Prüfen Sie mithilfe der RDS-Konsole, der oder der RDS-API, ob ein Wartungsupdate für Ihren verfügbar ist. AWS CLI Wenn ein Update verfügbar ist, wird dies in der Amazon-RDS-Konsole in der Spalte **Wartung** für die den DB-Cluster angegeben, wie in der folgenden Abbildung gezeigt.
![\[Die Wartungsaktion ist verfügbar und wird beim nächsten Wartungsfenster angewendet.\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/images/offlinepatchavailable.png)
Wenn für eienn DB-Cluster keine Aktualisierung verfügbar ist, lautet ihr bzw. sein Spaltenwert **none (keine)**.
Wenn eine Wartungsaktualisierung für einen DB-Cluster verfügbar ist, sind die folgenden Spaltenwerte möglich:
+ **required (erforderlich) ** – Die Wartungsaktion wird auf die Ressource angewendet und kann nicht unbegrenzt aufgeschoben werden.
+ **available (verfügbar)** – Die Wartungsaktion ist verfügbar, wird aber nicht automatisch auf die Ressource angewandt. Sie können sie manuell anwenden.
+ **next window (nächstes Fenster)** – Die Wartungsmaßnahme wird im nächsten Wartungsfenster auf die Ressource angewandt.
+ **Läuft** – Die Wartungsmaßnahme wird derzeit auf die Ressource angewandt.
Wenn ein Update verfügbar ist, können Sie eine der folgenden Aktionen durchführen:
+ Wenn der Wartungswert **nächstes Fenster** ist, schieben Sie die Wartungselemente durch Auswahl von **Upgrade aufschieben** in **Aktionen** auf. Sie können eine bereits gestartete Wartungsaktion nicht verschieben.
+ Wenden Sie die Wartungsaktionen sofort an.
+ Wenden Sie die Wartungsaktionen für des nächsten Wartungsfensters an.
+ Keine Aktion.
**Um eine Maßnahme zu ergreifen, verwenden Sie AWS-Managementkonsole**
1. Wählen Sie die DB-Instance oder den DB-Cluster aus, um die zugehörigen Details anzuzeigen.
1. Wählen Sie **Wartung und Sicherungen** aus. Die ausstehenden Wartungsaktionen werden angezeigt.
1. Wählen Sie die zu ergreifende Maßnahme aus und wählen Sie dann den Zeitpunkt ihrer Anwendung aus.
![\[Ausstehender Wartungsposten für eine Aurora-DB-Instance.\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/images/pending_maintenance_aurora_instance.png)
Der Wartungszeitraum legt fest, wann die ausstehenden Operationen gestartet werden, gibt aber keine Gesamtlaufzeit für diese Operationen vor. Wartungsarbeiten werden nicht zwingend vor Ende des Wartungszeitraums abgeschlossen. Sie können daher über die angegebene Endzeit hinaus fortgesetzt werden. Weitere Informationen finden Sie unter [Amazon-RDS-Wartungsfenster](#Concepts.DBMaintenance).
Sie können auch überprüfen, ob ein Wartungsupdate für Ihren verfügbar ist, indem Sie den [describe-pending-maintenance-actions](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-pending-maintenance-actions.html) AWS CLI Befehl ausführen.
Weitere Informationen zum Anwenden von Wartungsupdates finden Sie unter [Updates auf einen anwenden](#USER_UpgradeDBInstance.OSUpgrades).
### Wartungsaktionen für Amazon Aurora
Die folgenden Wartungsaktionen gelten für Aurora-DB-Cluster:
+ `os-upgrade` – Aktualisieren Sie die Betriebssysteme aller DB-Instances im DB-Cluster mithilfe von fortlaufenden Upgrades. Weitere Informationen finden Sie unter [Betriebssystemupdates für Aurora-DB-Cluster](#Aurora_OS_updates).
+ `system-update` – Patchen Sie die DB-Engine für Aurora PostgreSQL.
Die folgenden Wartungsaktionen gelten für Aurora-DB-Instances:
+ `ca-certificate-rotation` – Aktualisieren Sie das Zertifikat der Amazon-RDS-Zertifizierungsstelle für die DB-Instance.
+ `hardware-maintenance` – Führen Sie Wartungsarbeiten an der zugrunde liegenden Hardware für die DB-Instance durch.
+ `system-update` – Aktualisieren Sie das Betriebssystem für die DB-Instance.
## Auswahl der Häufigkeit der Aurora MySQL-Wartungsupdates
Sie können steuern, ob Aurora MySQL-Upgrades für jeden DB-Cluster häufig oder selten stattfinden. Die beste Wahl hängt von Ihrer Verwendung von Aurora MySQL und den Prioritäten für Ihre Anwendungen ab, die unter Aurora ausgeführt werden. Informationen über die Aurora-MySQL-LTS-Versionen (Langzeitstabilität), die weniger häufige Upgrades erfordern, finden Sie unter[Aurora MySQL Long-Term Support- (LTS, Langzeit-Support) Versionen](AuroraMySQL.Update.SpecialVersions.md#AuroraMySQL.Updates.LTS)aus.
Sie können einen Aurora MySQL-Cluster selten aktualisieren, wenn einige oder alle der folgenden Bedingungen zutreffen:
+ Ihr Testzyklus für Ihre Anwendung dauert bei einer Aktualisierung der Aurora MySQL-Datenbank-Engine sehr lange.
+ Sie haben viele DB-Cluster oder viele Anwendungen, die alle auf der gleichen Aurora MySQL-Version ausgeführt werden. Sie ziehen es vor, alle Ihre DB-Cluster und die zugehörigen Anwendungen gleichzeitig upzugraden.
+ Sie verwenden sowohl Aurora MySQL als auch RDS für MySQL. Sie möchten, dass die Aurora-MySQL-Cluster und die DB-Instances von RDS für MySQL mit demselben MySQL-Level kompatibel bleiben.
+ Ihre Aurora MySQL-Anwendung befindet sich in der Produktion oder ist anderweitig geschäftskritisch. Sie können sich keine Ausfallzeiten für Upgrades außerhalb seltener Fälle für kritische Patches leisten.
+ Ihre Aurora MySQL-Anwendung ist nicht durch Leistungsprobleme oder Funktionslücken eingeschränkt, die in nachfolgenden Aurora MySQL-Versionen behoben werden.
Wenn die vorstehenden Faktoren auf Ihre Situation zutreffen, können Sie die Anzahl der erzwungenen Upgrades für einen Aurora MySQL DB-Cluster begrenzen. Dies geschieht, indem Sie beim Erstellen oder Aktualisieren dieses DB-Clusters eine bestimmte Aurora MySQL-Version wählen, die als "Long-Term Support" (LTS)-Version bekannt ist. Dadurch wird die Anzahl der Upgrade-Zyklen, Testzyklen und upgradebedingten Ausfälle für diesen DB-Cluster minimiert.
Sie können einen Aurora MySQL-Cluster häufig aktualisieren, wenn einige oder alle der folgenden Bedingungen zutreffen:
+ Der Testzyklus für Ihre Anwendung ist unkompliziert und kurz.
+ Ihre Anwendung befindet sich noch in der Entwicklungsphase.
+ Ihre Datenbankumgebung verwendet eine Vielzahl von Aurora MySQL-Versionen oder Aurora MySQL- und RDS für MySQL-Versionen. Jeder Aurora MySQL-Cluster hat seinen eigenen Upgrade-Zyklus.
+ Sie warten auf spezifische Leistungs- oder Funktionsverbesserungen, bevor Sie Ihre Nutzung von Aurora MySQL erhöhen.
Wenn die vorhergehenden Faktoren auf Ihre Situation zutreffen, können Sie Aurora aktivieren, um wichtige Upgrades häufiger anzuwenden. Dazu führen Sie ein Upgrade eines DB-Clusters von Aurora MySQL auf eine aktuellere Version von Aurora MySQL als die LTS-Version durch. Auf diese Weise stehen Ihnen die neuesten Leistungssteigerungen, Bugfixes und Funktionen schneller zur Verfügung.
## Amazon-RDS-Wartungsfenster
Das Wartungsfenster ist ein wöchentliches Zeitintervall, in dem alle Systemänderungen übernommen werden. Jede DB–jeder DB-Cluster verfügt über ein wöchentliches Wartungsfenster. Das Wartungsfenster ist eine Möglichkeit, zu kontrollieren, wann Änderungen und Software-Patches auftreten. Weitere Informationen über Wartungsfenster finden Sie unter [Anpassen des bevorzugten DB-Cluster-Wartungsfensters](#AdjustingTheMaintenanceWindow.Aurora).
RDS verbraucht während der Wartung einige Ressourcen auf Ihrem DB-Cluster. Sie können einen minimalen Einfluss auf die Leistung beobachten. Bei einer DB-Instance kann in seltenen Fällen ein Multi-AZ-Failover erforderlich sein, damit ein Wartungs-Update abgeschlossen werden kann.
Wenn ein Wartungsereignis für eine bestimmte Woche geplant ist, wird es während des 30-minütigen Wartungsfensters eingeleitet, das Sie festlegen. Die meisten Wartungsereignisse werden auch während des 30-minütigen Wartungsfensters abgeschlossen, obwohl größere Wartungsereignisse länger als 30 Minuten dauern können. Das Wartungsfenster wird angehalten, wenn die der DB-Cluster gestoppt wird.
Das 30-minütige Wartungsfenster wird zufällig aus einem 8-Stunden-Zeitraum pro Region ausgewählt. Wenn Sie beim Erstellen des DB-Clusters kein Wartungsfenster angeben, legt RDS ein 30-minütiges Wartungsfenster an einem zufällig ausgewählten Wochentag fest.
In der folgenden Tabelle sind die Zeitblöcke für die einzelnen AWS-Region Zeitblöcke aufgeführt, denen die Standard-Wartungsfenster zugewiesen wurden.
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.Maintenance.html)
**Topics**
+ [Anpassen des bevorzugten DB-Cluster-Wartungsfensters](#AdjustingTheMaintenanceWindow.Aurora)
### Anpassen des bevorzugten DB-Cluster-Wartungsfensters
Der Wartungszeitraum für ein Aurora-DB-Cluster sollte in den Zeitraum mit der geringsten Nutzung fallen und daher unter Umständen von Zeit zu Zeit geändert werden. Ihr DB-Cluster ist während dieser Zeit nur dann nicht verfügbar, wenn die Updates, die angewendet werden, einen Ausfall erfordern. Der Ausfall dauert die minimale Zeit, die erforderlich ist, um die notwendigen Aktualisierungen vorzunehmen.
**Anmerkung**
Für Upgrades zur Datenbank-Engine verwaltet Amazon Aurora das bevorzugte Wartungsfenster für ein DB-Cluster und nicht für einzelne Instances.
#### Konsole
**So passen Sie den bevorzugten DB-Cluster-Wartungszeitraum an**
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 **Datenbanken** aus.
1. Wählen Sie das DB-Cluster aus, für das Sie den Wartungszeitraum ändern möchten.
1. Wählen Sie **Ändern** aus.
1. Aktualisieren Sie im Bereich **Wartung** den Wartungszeitraum.
1. Klicken Sie auf **Weiter**.
Überprüfen Sie auf der Bestätigungsseite Ihre Änderungen.
1. Um die Änderungen sofort auf das Wartungsfenster anzuwenden, wählen Sie im Abschnitt **Schedule of modifications (Änderungsplan)** die Option **Immediately (Sofort)** .
1. Wählen Sie **Cluster ändern** aus, um Ihre Änderungen zu speichern.
Klicken Sie anderenfalls auf **Zurück**, um Ihre Änderungen zu bearbeiten, oder klicken Sie auf **Abbrechen**, um Ihre Änderungen zu verwerfen.
#### AWS CLI
Um das bevorzugte Wartungsfenster für den DB-Cluster anzupassen, verwenden Sie den AWS CLI [https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html)Befehl mit den folgenden Parametern:
+ `--db-cluster-identifier`
+ `--preferred-maintenance-window`
**Example**
Im folgenden Codebeispiel wird der Wartungszeitraum auf dienstags von 4:00 Uhr bis 4:30 Uhr (UTC) festgelegt.
Für Linux, macOS oder Unix:
```
aws rds modify-db-cluster \
--db-cluster-identifier my-cluster \
--preferred-maintenance-window Tue:04:00-Tue:04:30
```
Für Windows:
```
aws rds modify-db-cluster ^
--db-cluster-identifier my-cluster ^
--preferred-maintenance-window Tue:04:00-Tue:04:30
```
#### RDS-API
Verwenden Sie die Amazon-RDS-API-Operaion [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html) mit den folgenden Parametern, um das bevorzugte Wartungsfenster für Ihren DB-Cluster anzupassen:
+ `DBClusterIdentifier`
+ `PreferredMaintenanceWindow`
## Updates auf einen anwenden
Mit Amazon RDS können Sie auswählen, zu welchem Zeitpunkt Wartungsoperationen angewendet werden sollen. Mithilfe der, oder RDS-API können Sie entscheiden AWS-Managementkonsole AWS CLI, wann Amazon RDS Updates einführt.
### Konsole
**Verwalten eines Update für einen DB-Cluster**
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 **Datenbanken** aus.
1. Wählen Sie den DB-Cluster aus, für die/den ein erforderliches Update angegeben ist.
1. Wählen Sie unter **Aktionen** eine der folgenden Optionen:
+ **Jetzt patchen**
+ **Im nächsten Fenster patchen**
**Anmerkung**
Wenn Sie **Im nächsten Wartungszeitraum Upgrade ausführen** auswählen und die Installation des Updates aufschieben möchten, können Sie die Option **Upgrade verschieben** auswählen. Sie können eine Wartungsaktion nicht verschieben, wenn sie bereits gestartet wurde.
Um eine Wartungsaktion abzubrechen, ändern Sie die DB-Instance und deaktivieren Sie **Auto minor version upgrade (Automatisches Upgrade einer Unterversion)**.
### AWS CLI
Verwenden Sie den [apply-pending-maintenance-action](https://docs.aws.amazon.com/cli/latest/reference/rds/apply-pending-maintenance-action.html) AWS CLI Befehl, um ein ausstehendes Update auf einen anzuwenden.
**Example**
Für Linux, macOS oder Unix:
```
aws rds apply-pending-maintenance-action \
--resource-identifier arn:aws:rds:us-west-2:001234567890:db:mysql-db \
--apply-action system-update \
--opt-in-type immediate
```
Für Windows:
```
aws rds apply-pending-maintenance-action ^
--resource-identifier arn:aws:rds:us-west-2:001234567890:db:mysql-db ^
--apply-action system-update ^
--opt-in-type immediate
```
**Anmerkung**
Um eine Wartungsaktion zu verschieben, geben Sie `undo-opt-in` für `--opt-in-type` an. Sie können `undo-opt-in` nicht für `--opt-in-type` angeben, wenn die Wartungsaktion bereits gestartet wurde.
Um eine Wartungsaktion abzubrechen, führen Sie den [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html) AWS CLI Befehl aus und geben Sie Folgendes an`--no-auto-minor-version-upgrade`.
Verwenden Sie den [describe-pending-maintenance-actions](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-pending-maintenance-actions.html) AWS CLI Befehl, um eine Liste der Ressourcen zurückzugeben, für die mindestens ein Update aussteht.
**Example**
Für Linux, macOS oder Unix:
```
aws rds describe-pending-maintenance-actions \
--resource-identifier arn:aws:rds:us-west-2:001234567890:db:mysql-db
```
Für Windows:
```
aws rds describe-pending-maintenance-actions ^
--resource-identifier arn:aws:rds:us-west-2:001234567890:db:mysql-db
```
Sie können auch eine Liste von Ressourcen für einen zurückgeben, indem Sie den `--filters` Parameter des `describe-pending-maintenance-actions` AWS CLI Befehls angeben. Der Befehl hat das folgende Format für `--filters`: `Name=filter-name,Value=resource-id,...`.
Für den `Name`-Parameter eines Filters sind folgende Werte gültig:
+ `db-instance-id`— Akzeptiert eine Liste von DB-Instance-Identifikatoren oder Amazon-Ressourcennamen (ARNs). Die zurückgegebene Liste enthält nur ausstehende Wartungsaktionen für die DB-Instances, die durch diese Identifikatoren oder identifiziert wurden. ARNs
+ `db-cluster-id`— Akzeptiert eine Liste von DB-Cluster-Identifikatoren oder ARNs für Amazon Aurora. Die zurückgegebene Liste enthält nur ausstehende Wartungsaktionen für die DB-Cluster, die anhand dieser Kennungen oder identifiziert wurden. ARNs
In dem folgenden Beispiel wird eine Liste der aussehenden Wartungsaktionen für die DB-Cluster `sample-cluster1` und `sample-cluster2` zurückgegeben.
**Example**
Für Linux, macOS oder Unix:
```
aws rds describe-pending-maintenance-actions \
--filters Name=db-cluster-id,Values=sample-cluster1,sample-cluster2
```
Für Windows:
```
aws rds describe-pending-maintenance-actions ^
--filters Name=db-cluster-id,Values=sample-cluster1,sample-cluster2
```
### RDS-API
Rufen Sie die Amazon-RDS-API-Operation [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ApplyPendingMaintenanceAction.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ApplyPendingMaintenanceAction.html) auf, um ein Update auf einem DB-Cluster zu installieren.
Rufen Sie die Amazon-RDS-API-Operation [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribePendingMaintenanceActions.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribePendingMaintenanceActions.html) auf, um eine Liste der Ressourcen zurückzugeben, für die mindestens ein Update aussteht.
## Automatische Nebenversions-Upgrades für Aurora-DB-Cluster
Die Einstellung **Automatisches Unterversion-Upgrade** gibt an, ob Aurora Upgrades automatisch auf den DB-Cluster anwendet. Diese Upgrades umfassen neue Unterversionen mit zusätzlichen Funktionen und Patches mit Bugfixes.
Durch automatische Nebenversions-Upgrades wird Ihre Datenbank regelmäßig auf die neuesten Datenbank-Engine-Versionen aktualisiert. Das Upgrade beinhaltet jedoch möglicherweise nicht immer die aktuelle Datenbank-Engine-Version. Wenn Sie Ihre Datenbanken zu bestimmten Zeiten auf bestimmten Versionen belassen müssen, empfehlen wir Ihnen, ein manuelles Upgrade auf die Datenbankversionen durchzuführen, die Sie gemäß Ihrem erforderlichen Zeitplan benötigen. Bei kritischen Sicherheitsproblemen oder wenn eine Version ihr end-of-support Datum erreicht, führt Aurora möglicherweise ein Upgrade einer Nebenversion durch, auch wenn Sie die Option **Automatisches Upgrade der Nebenversion** nicht aktiviert haben. Weitere Informationen finden Sie in der Upgrade-Dokumentation zu Ihrer spezifischen Datenbank-Engine.
Siehe [Upgrade der Nebenversion oder der Patch-Ebene eines Aurora MySQL-DB-Clusters](AuroraMySQL.Updates.Patching.md) und [Durchführen eines Nebenversions-Upgrades](USER_UpgradeDBInstance.PostgreSQL.MinorUpgrade.md).
**Anmerkung**
Die globale Aurora-Datenbank unterstützt keine automatischen Unterversion-Upgrades.
Diese Einstellung ist standardmäßig aktiviert. Wählen Sie für jeden neuen DB-Cluster den entsprechenden Wert für diese Einstellung aus. Dieser Wert basiert auf der Wichtigkeit, der erwarteten Lebensdauer und dem Umfang der Verifizierungstests, die Sie nach jedem Upgrade durchführen.
Anleitungen zum Ein- und Ausschalten der Einstellung **Automatisches Unterversion-Upgrade** finden Sie im Folgenden:
+ [Aktivieren automatischer Nebenversions-Upgrades für einen Aurora-DB-Cluster](#aurora-amvu-cluster)
+ [Aktivieren automatischer Unterversion-Upgrades für einzelne DB-Instances in einem Aurora-DB-Cluster](#aurora-amvu-instance)
**Wichtig**
Wir empfehlen dringend, dass Sie diese Einstellung für neue und bestehende DB-Cluster auf den DB-Cluster anwenden und nicht einzeln auf die DB-Instances im Cluster. Wenn diese Einstellung für eine DB-Instance in Ihrem Cluster deaktiviert ist, wird der DB-Cluster nicht automatisch aktualisiert.
Die folgende Tabelle zeigt, wie die Einstellung **Automatisches Unterversion-Upgrade** funktioniert, wenn sie auf Cluster- und Instance-Ebene angewendet wird.
| Action | Cluster-Einstellung | Instance-Einstellungen | Wurde der Cluster automatisch aktualisiert? |
| --- | --- | --- | --- |
| Sie legen diese Einstellung im DB-Cluster auf „true“ fest. | Wahr | „True“ für alle neuen und bestehenden Instances | Ja |
| Sie legen diese Einstellung im DB-Cluster auf „false“ fest. | Falsch | „False“ für alle neuen und bestehenden Instances | Nein |
| Die Einstellung wurde zuvor im DB-Cluster auf „true“ festgelegt. Sie legen sie auf mindestens einer DB-Instance auf „false“ fest. | Ändert sich in „false“ | „False“ für eine oder mehrere Instances | Nein |
| Die Einstellung wurde zuvor im DB-Cluster auf „false“ festgelegt. Sie legen die Einstellung für mindestens eine, aber nicht für alle DB-Instances auf „true“ fest. | Falsch | „True“ für eine oder mehrere Instances, aber nicht für alle Instances | Nein |
| Die Einstellung wurde zuvor im DB-Cluster auf „false“ festgelegt. Sie legen die Einstellung für alle DB-Instances auf „true“ fest. | Ändert sich in „true“ | „True“ für alle Instances | Ja |
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 Ereignisnachrichten für Aurora](USER_Events.Messages.md).
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.
Weitere Informationen über Engine-Updates für Aurora PostgreSQL finden Sie unter [Aktualisierungen der Datenbank-Engine für Amazon Aurora PostgreSQL](AuroraPostgreSQL.Updates.md).
Weitere Informationen zur Einstellung für **automatische Nebenversions-Upgrades** für Aurora MySQL finden Sie unter [Aktivieren von automatischen Upgrades zwischen Aurora MySQL-Nebenversionen](AuroraMySQL.Updates.AMVU.md). Weitere Informationen über Engine-Updates für Aurora MySQL finden Sie unter [Datenbank-Engine-Updates für Amazon Aurora MySQLLTS-Versionen (Long-Term-Support, Langzeit-Support) und Betaversionen für Amazon Aurora MySQL](AuroraMySQL.Updates.md).
**Topics**
### Aktivieren automatischer Nebenversions-Upgrades für einen Aurora-DB-Cluster
Gehen Sie vor, wie im allgemeinen Verfahren unter [Ändern des DB-Clusters über die Konsole, die CLI und die API](Aurora.Modifying.md#Aurora.Modifying.Cluster) beschrieben.
**Konsole**
Wählen Sie im Abschnitt **Wartung** der Seite **DB-Cluster ändern** das Kontrollkästchen **Automatisches Nebenversions-Upgrade aktivieren** aus.
**AWS CLI**
Führen Sie den Befehl [modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html) AWS CLI aus. Geben Sie den Namen Ihres DB-Clusters für die `--db-cluster-identifier`-Option und `true` für die `--auto-minor-version-upgrade`-Option an. Optional können Sie die `--apply-immediately`-Option angeben, um diese Einstellung sofort für Ihren DB-Cluster zu aktivieren.
**RDS-API**
Rufen Sie den Vorgang „DBClusterAPI [modifizieren](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html)“ auf und geben Sie den Namen Ihres DB-Clusters für den `DBClusterIdentifier` Parameter und `true` für den `AutoMinorVersionUpgrade` Parameter an. Legen Sie optional den Parameter `ApplyImmediately` auf `true` fest, um diese Einstellung für Ihren DB-Cluster sofort zu aktivieren.
### Aktivieren automatischer Unterversion-Upgrades für einzelne DB-Instances in einem Aurora-DB-Cluster
Gehen Sie vor, wie im allgemeinen Verfahren unter [Ändern einer DB-Instance in einem DB-Cluster](Aurora.Modifying.md#Aurora.Modifying.Instance) beschrieben.
**Konsole**
Wählen Sie im Abschnitt **Wartung** der Seite **DB-Instance ändern** das Kontrollkästchen **Automatisches Nebenversions-Upgrade aktivieren** aus.
**AWS CLI**
Führen Sie den Befehl [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html) AWS CLI aus. Geben Sie den Namen Ihrer DB-Instance für die `--db-instance-identifier`-Option und `true` für die `--auto-minor-version-upgrade`-Option an. Optional können Sie die `--apply-immediately`-Option angeben, um diese Einstellung sofort für Ihre DB-Instance zu aktivieren. Führen Sie einen separaten `modify-db-instance`-Befehl für jede DB-Instance in dem Cluster aus.
**RDS-API**
Rufen Sie den DBInstance API-Vorgang [Modify](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html) auf und geben Sie den Namen Ihres DB-Clusters für den `DBInstanceIdentifier` Parameter und `true` für den `AutoMinorVersionUpgrade` Parameter an. Legen Sie optional den Parameter `ApplyImmediately` auf `true` fest, um diese Einstellung für Ihre DB-Instance sofort zu aktivieren. Rufen Sie für jede DB-Instance in dem Cluster eine separate `ModifyDBInstance`-Operation auf.
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-writer-instance",
"DBClusterIdentifier": "my-db-cluster-57",
"AutoMinorVersionUpgrade": true
},
{
"DBInstanceIdentifier": "db-reader-instance1",
"DBClusterIdentifier": "my-db-cluster-57",
"AutoMinorVersionUpgrade": false
},
{
"DBInstanceIdentifier": "db-writer-instance2",
"DBClusterIdentifier": "my-db-cluster-80",
"AutoMinorVersionUpgrade": true
},
... output omitted ...
```
In diesem Beispiel ist die Einstellung **Automatisches Nebenversions-Upgrade aktivieren** für den DB-Cluster `my-db-cluster-57` deaktiviert, da sie für eine der DB-Instances im Cluster deaktiviert ist.
## Betriebssystemupdates für Aurora-DB-Cluster
DB-Instances in DB-Cluster von Aurora MySQL und Aurora PostgreSQL erfordern gelegentlich Betriebssystemaktualisierungen. Amazon RDS aktualisiert das Betriebssystem auf eine neuere Version, um die Datenbankleistung und der allgemeine Sicherheitsstatus der Kunden zu verbessern. In der Regel dauern die Updates etwa 10 Minuten. Betriebssystemupdates ändern nicht die DB-Engine-Version oder die DB-Instance-Klasse einer DB-Instance.
Es gibt zwei Arten von Betriebssystemupdates, die sich durch die Beschreibung der ausstehenden Wartungsaktion unterscheiden:
+ **Upgrade der Betriebssystemdistribution** – Wird für die Migration auf die neueste unterstützte Hauptversion von Amazon Linux verwendet. Die Beschreibung lautet `New Operating System upgrade is available`.
+ **Betriebssystem-Patch** – Wird verwendet, um verschiedene Sicherheitskorrekturen anzuwenden und manchmal um die Datenbankleistung zu verbessern. Die Beschreibung lautet `New Operating System patch is available`.
Betriebssystemupdates können entweder optional oder obligatorisch sein:
+ Ein **optionales Update** kann jederzeit angewendet werden. Obwohl diese Updates optional sind, empfehlen wir Ihnen, sie regelmäßig anzuwenden, um Ihre RDS-Flotte auf dem neuesten Stand zu halten. RDS wendet diese Updates *nicht* automatisch an.
Wenn Sie benachrichtigt werden möchten, sobald ein neuer optionaler System-Patch verfügbar ist, können Sie [RDS-EVENT-0230](USER_Events.Messages.md#RDS-EVENT-0230) in der Kategorie „Sicherheitspatch-Ereignis“ abonnieren. Informationen zum Abonnieren von RDS-Ereignissen finden Sie unter [Abonnieren von Amazon-RDS-Ereignisbenachrichtigungen](USER_Events.Subscribing.md).
**Anmerkung**
`RDS-EVENT-0230` gilt nicht für Upgrades der Betriebssystemdistribution.
+ Ein **obligatorisches Update** ist erforderlich. Wir senden vor dem obligatorischen Update eine Benachrichtigung. Die Benachrichtigung kann ein Fälligkeitsdatum enthalten. Planen Sie Ihr Update vor diesem Fälligkeitsdatum. Nach dem angegebenen Fälligkeitsdatum aktualisiert Amazon RDS das Betriebssystem für Ihre DB-Instance während eines Ihrer zugewiesenen Wartungsfenster automatisch auf die neueste Version.
Upgrades der Betriebssystemdistribution sind obligatorisch.
**Anmerkung**
Es ist möglicherweise erforderlich, im Hinblick auf alle optionalen und obligatorischen Updates auf dem Laufenden zu bleiben, um verschiedene Compliance-Auflagen zu erfüllen. Wir empfehlen Ihnen, alle von RDS zur Verfügung gestellten Updates während Ihrer Wartungsfenster routinemäßig anzuwenden.
Für Aurora-DB-Cluster können Sie die Wartungsoption auf **Cluster-Ebene** verwenden, um Betriebssystem (BS)-Updates durchzuführen. Suchen Sie auf der Registerkarte **Wartung und Sicherungen** nach der Option zur Durchführung von Updates auf Cluster-Ebene, wenn Sie den Namen Ihres DB-Clusters in der Konsole auswählen, oder verwenden Sie den `os-upgrade`-Befehl in der AWS CLI. Diese Methode bewahrt die Leseverfügbarkeit durch fortlaufende Upgrades, bei denen Updates automatisch auf mehrere Leser-DB-Instances gleichzeitig angewendet werden. Um mehrere Failover zu verhindern und unnötige Ausfallzeiten zu reduzieren, aktualisiert Aurora die Writer-DB-Instance zuletzt.
Betriebssystemupdates auf Cluster-Ebene erfolgen während des Wartungsfensters, das Sie für den Cluster angegeben haben. Dadurch werden koordinierte Updates für den gesamten Cluster sichergestellt.
Aus Gründen der Abwärtskompatibilität behält Aurora auch die Wartungsoption auf **Instance-Ebene ** bei. Wir empfehlen jedoch, stattdessen Updates auf Cluster-Ebene zu verwenden. Wenn Sie Updates auf Instance-Ebene verwenden müssen, aktualisieren Sie zuerst die Reader-DB-Instances in einem DB-Cluster und dann die Writer-DB-Instance. Wenn Sie Reader- und Writer-Instances gleichzeitig aktualisieren, erhöhen Sie die Wahrscheinlichkeit von Ausfallzeiten im Zusammenhang mit einem Failover. Suchen Sie auf der Registerkarte **Wartung und Sicherungen** nach der Option zum Durchführen von Updates auf Instance-Ebene, wenn Sie den Namen Ihrer DB-Instance in der Konsole auswählen, oder verwenden Sie den Befehl `system-update` in der AWS CLI-
Betriebssystemupdates auf Instance-Ebene erfolgen während des Wartungsfensters, das Sie für die jeweilige Instance angegeben haben. Wenn beispielsweise ein Cluster und zwei Reader-Instances unterschiedliche Wartungsfensterzeiten haben, richtet sich ein Betriebssystemupdate auf Cluster-Ebene nach dem Wartungsfenster des Clusters.
Sie können das AWS-Managementkonsole oder das verwenden AWS CLI , um Informationen über die Art des Betriebssystem-Upgrades abzurufen.
### Konsole
**Um Aktualisierungsinformationen zu erhalten, verwenden Sie den AWS-Managementkonsole**
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 anschließend die MySQL-DB-Instance aus.
1. Wählen Sie **Wartung und Sicherungen** aus.
1. Suchen Sie im Abschnitt **Ausstehende Wartungen** das Betriebssystemupdate und überprüfen Sie den Wert **Beschreibung**.
Die folgenden Abbildungen zeigen einen DB-Cluster mit einer Writer-DB-Instance, für die ein Betriebssystem-Patch verfügbar ist.
![\[Betriebssystem-Patch auf Cluster-Ebene\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/images/os-upgrade-cluster-minor.png)
![\[Betriebssystem-Patch auf Instance-Ebene.\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/images/os-upgrade-writer-minor.png)
Die folgenden Abbildungen zeigen einen DB-Cluster mit einer Writer-DB-Instance und einer Reader-DB-Instance Für die Writer-Instance ist ein obligatorisches Betriebssystem-Upgrade verfügbar. Für die Reader-Instance ist ein Betriebssystem-Patch verfügbar.
![\[Upgrade der Betriebssystemdistribution auf Cluster-Ebene\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/images/os-upgrade-cluster-major.png)
![\[Upgrade der Betriebssystemdistribution der Writer-Instance\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/images/os-upgrade-writer-major.png)
![\[Betriebssystem-Patch für die Reader-Instance\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/images/os-upgrade-reader-minor.png)
### AWS CLI
Verwenden Sie den [describe-pending-maintenance-actions](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-pending-maintenance-actions.html)Befehl AWS CLI, um Aktualisierungsinformationen von zu erhalten.
```
aws rds describe-pending-maintenance-actions
```
Die folgende Ausgabe zeigt ein Upgrade einer Betriebssystemdistribution für einen DB-Cluster und eine DB-Instance.
```
{
"PendingMaintenanceActions": [
{
"ResourceIdentifier": "arn:aws:rds:us-east-1:123456789012:cluster:t3",
"PendingMaintenanceActionDetails": [
{
"Action": "os-upgrade",
"Description": "New Operating System upgrade is available"
}
]
},
{
"ResourceIdentifier": "arn:aws:rds:us-east-1:123456789012:db:t3-instance1",
"PendingMaintenanceActionDetails": [
{
"Action": "system-update",
"Description": "New Operating System upgrade is available"
}
]
},
]
}
```
Die folgende Ausgabe zeigt einen Betriebssystem-Patch für eine DB-Instance.
```
{
"ResourceIdentifier": "arn:aws:rds:us-east-1:123456789012:db:mydb2",
"PendingMaintenanceActionDetails": [
{
"Action": "system-update",
"Description": "New Operating System patch is available"
}
]
}
```
### Verfügbarkeit von Betriebssystemupdates
Betriebssystemupdates sind spezifisch für die DB-Engine-Version und die DB-Instance-Klasse. Daher erhalten oder erfordern DB-Instances Updates zu verschiedenen Zeiten. Wenn für Ihre DB-Instance basierend auf der Engine-Version und der Instance-Klasse ein Betriebssystemupdate erforderlich ist, wird das erforderliche Update in der Konsole angezeigt. Es kann auch angezeigt werden, indem [describe-pending-maintenance-actions](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-pending-maintenance-actions.html) AWS CLI Sie den Befehl ausführen oder den [DescribePendingMaintenanceActions](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribePendingMaintenanceActions.html)RDS-API-Vorgang aufrufen. Wenn für Ihre Instance ein Update verfügbar ist, können Sie Ihr Betriebssystem aktualisieren, indem Sie den Anleitungen unter [Updates auf einen anwenden](#USER_UpgradeDBInstance.OSUpgrades) folgen.
# Verwendung der AWS Organizations Upgrade-Rollout-Richtlinie für automatische Upgrades kleinerer Versionen
Aurora unterstützt AWS Organizations Upgrade-Rollout-Richtlinien zur Verwaltung automatischer Upgrades kleinerer Versionen für mehrere Datenbankressourcen und AWS-Konten. Diese Richtlinie unterstützt Sie bei der Implementierung einer kontrollierten Upgrade-Strategie für Ihre Cluster durch:
**So funktioniert die Upgrade-Rollout-Richtlinie**
Wenn eine neue Engine-Nebenversion für ein automatisches Upgrade in Frage kommt, steuert die Richtlinie die Upgrade-Sequenz auf der Grundlage definierter Bestellungen:
+ Ressourcen, die als [zuerst] gekennzeichnet sind (in der Regel Entwicklungsumgebungen), kommen während ihrer Wartungsfenster für Upgrades in Frage.
+ Nach Ablauf einer bestimmten Backzeit kommen Ressourcen, die als [zweite] markiert sind, für sie in Frage.
+ Nach einer weiteren festgelegten Backzeit kommen Ressourcen, die als [zuletzt] markiert sind (in der Regel Produktionsumgebungen), in Frage.
+ Überwachung des Upgrade-Fortschritts mithilfe von AWS Health-Benachrichtigungen.
Sie können Ihre Upgrade-Bestellungen wie folgt definieren:
+ Richtlinien auf Kontoebene — Gilt für alle berechtigten Ressourcen in bestimmten Konten.
+ Ressourcen-Tags — Gilt für bestimmte Ressourcen, die auf Tags basieren.
**Anmerkung**
Ressourcen, die nicht mit einer Upgrade-Richtlinie konfiguriert oder von der Richtlinie ausgeschlossen sind, erhalten automatisch eine Upgrade-Reihenfolge von [Sekunde].
**Voraussetzungen**
+ Sie AWS-Konto müssen Teil einer Organisation in Organizations sein, für die Upgrade-Rollout-Richtlinie aktiviert ist
+ Aktivieren Sie automatische Upgrades für kleinere Versionen für Ihre Cluster
+ Tags sind für die Upgrade-Rollout-Richtlinie nicht unbedingt erforderlich. Wenn Sie spezifische Upgrade-Bestellungen für verschiedene Umgebungen (z. B. Entwicklung, Test, Qualitätssicherung, Produktion) definieren möchten, können Sie Tags verwenden. Wenn Sie keine Tag-Einstellungen in Ihre Richtlinie aufnehmen, folgen alle Ressourcen, die dieser Richtlinie unterliegen, der Standard-Upgrade-Reihenfolge. Für Aurora-Ressourcen werden nur Tags auf Clusterebene für die Upgrade-Rollout-Richtlinie verwendet, auch wenn Sie Tags auf Instanzebene definiert haben.
**Um Ihre Ressourcen zu taggen**
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 **Datenbanken** aus.
1. Wählen Sie den Cluster aus, den Sie taggen möchten.
1. Wählen Sie „**Aktionen**“ und anschließend „**Tags verwalten**“.
1. Wählen Sie **Add tag**.
1. Gib deinen Tag-Schlüssel (zum Beispiel „Umgebung“) und den Wert (zum Beispiel „Entwicklung“) ein
1. Wählen **Sie Tag hinzufügen** und dann **Speichern**.
Sie können Tags auch hinzufügen, indem Sie AWS CLI:
```
aws rds add-tags-to-resource \
--resource-name arn:aws:rds:region:account-number:cluster:cluster-name \
--tags Key=Environment,Value=Development
```
## Reihenfolge und Phasen des Upgrades
Die Upgrade-Rollout-Richtlinie unterstützt drei Upgrade-Bestellungen:
+ [first] — Wird in der Regel für Entwicklungs- oder Testumgebungen verwendet
+ [zweite] — Wird in der Regel für QA-Umgebungen verwendet. Standardreihenfolge für Ressourcen, wenn die Richtlinie nicht speziell konfiguriert ist
+ [last] — In der Regel für Produktionsumgebungen reserviert
Wenn eine neue Minor-Engine-Version für ein automatisches Upgrade in Frage kommt:
+ Ressourcen mit einem Upgrade-Auftrag [zuerst] kommen für Upgrades während der konfigurierten Wartungsfenster in Frage.
+ Nach Ablauf einer bestimmten Wartezeit kommen Ressourcen mit Upgrade-Auftrag [zweiter] während ihrer Wartungsfenster für Upgrades in Frage.
+ Nach einer weiteren festgelegten Backzeit kommen Ressourcen mit Upgrade-Bestellung [zuletzt] während ihrer Wartungsfenster für Upgrades in Frage.
+ Die automatische Upgrade-Kampagne für kleinere Versionen endet, nachdem alle infrage kommenden Ressourcen mit Upgrade-Bestellungen [erste], [zweite] und [letzte] aktualisiert wurden oder wenn die Kampagne ihr geplantes Enddatum erreicht hat, je nachdem, was zuerst eintritt.
**Anmerkung**
Alle automatischen Upgrades der Nebenversionen werden während des für jeden Cluster konfigurierten Wartungsfensters durchgeführt, um mögliche Auswirkungen auf Ihre Anwendungen zu minimieren.
## Beobachtbarkeit
### AWS Health und Überwachung
Sie erhalten AWS Gesundheitsbenachrichtigungen:
+ Vor dem Start einer automatischen Upgrade-Kampagne für kleinere Versionen
+ Zwischen den einzelnen Phasen erfolgt der Übergang, um den Upgrade-Fortschritt besser verfolgen und überwachen zu können
+ Fortschrittsaktualisierungen mit der Anzahl der Ressourcen, die in Ihrer Flotte aktualisiert wurden, in der AWS Health-Konsole
Amazon RDS-Ereignisbenachrichtigungen:
+ Benachrichtigungen für Ressourcen, die für automatische Upgrades kleinerer Versionen aktiviert wurden, einschließlich:
+ Wenn Ihre Ressource aufgrund ihrer Upgrade-Bestellung ([erste], [zweite] oder [letzte]) für ein Upgrade in Frage kommt
+ Geplanter Upgrade-Zeitplan während des Wartungsfensters
+ Start- und Abschlussstatus des individuellen Datenbank-Upgrades
+ Abonnieren Sie diese Ereignisse über Amazon EventBridge 0 für eine automatisierte Überwachung
### Überlegungen
Einige Überlegungen, die Sie beachten sollten:
+ Die Richtlinie gilt für alle future automatischen Upgrade-Kampagnen für kleinere Versionen, einschließlich Richtlinienänderungen, die während aktiver Kampagnen vorgenommen wurden.
+ Wenn Sie an einer laufenden Upgrade-Kampagne teilnehmen, folgen Ihre Ressourcen der aktuellen Upgrade-Reihenfolge und warten nicht auf eine konfigurierte Richtlinie.
+ Ressourcen, die nicht mit einer Upgrade-Richtlinie konfiguriert oder von der Richtlinie ausgeschlossen sind, erhalten automatisch eine Upgrade-Reihenfolge von [Sekunde].
+ Die Richtlinie sieht Gültigkeitszeiträume zwischen den Upgrade-Phasen vor, bevor mit der nächsten Phase fortgefahren wird.
+ Es dauert einige Zeit, bis Änderungen an der Richtlinie oder den Ressourcen-Tags wirksam werden, bevor die neue Upgrade-Reihenfolge angewendet wird.
+ Die Richtlinie gilt nur für Aurora-Ressourcen, für die automatische Upgrades für kleinere Versionen aktiviert sind.
+ Wenn Sie ein Problem in einer Umgebung entdecken, können Sie automatische Upgrades für Nebenversionen für nachfolgende Umgebungen deaktivieren oder den Validierungszeitraum nutzen, um Probleme zu lösen, bevor die Upgrades mit der nächsten Upgrade-Bestellung fortgeführt werden.
Weitere Informationen zum Taggen von RDS-Ressourcen finden Sie unter[Taggen von Amazon Aurora- und Amazon RDS-Ressourcen](USER_Tagging.md). Ausführliche Anweisungen zur Einrichtung und Verwendung der Upgrade-Rollout-Richtlinie finden Sie AWS Organizations im *AWS Organizations Benutzerhandbuch* unter [Erste Schritte mit](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started.html).