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.
# Verwalten von Amazon Aurora MySQL
In den folgenden Abschnitten wird das Verwalten eines Amazon-Aurora-MySQL-DB-Clusters erläutert.
**Topics**
+ [Verwalten von Performance und Skalierung für Amazon Aurora MySQL](AuroraMySQL.Managing.Performance.md)
+ [Rückverfolgen eines Aurora-DB-Clusters](AuroraMySQL.Managing.Backtrack.md)
+ [Testen von Amazon Aurora MySQL unter Verwendung von Fehlersimulationsabfragen](AuroraMySQL.Managing.FaultInjectionQueries.md)
+ [Ändern von Tabellen in Amazon Aurora mithilfe von Fast DDL](AuroraMySQL.Managing.FastDDL.md)
+ [Anzeigen des Volume-Status für einen Aurora MySQL-DB-Cluster](AuroraMySQL.Managing.VolumeStatus.md)
# Verwalten von Performance und Skalierung für Amazon Aurora MySQL
## Skalierung von Aurora MySQL-DB-Instances
Sie können Aurora MySQL-DB-Instances auf zwei Arten skalieren, durch Skalierung der Instance oder durch Skalierung der Lesevorgänge. Weitere Informationen zur Lese-Skalierung finden Sie unter [Skalierung von Lesevorgängen](Aurora.Managing.Performance.md#Aurora.Managing.Performance.ReadScaling).
Sie können Ihr Aurora-MySQL-DB-Cluster skalieren, indem Sie die DB-Instance-Klasse für jede DB-Instance im DB-Cluster ändern. Aurora MySQL unterstützt mehrere DB-Instance-Klassen, die für Aurora optimiert sind. Verwenden Sie keine db.t2- oder db.t3-Instance-Klassen für größere Aurora-Cluster mit einer Größe von mehr als 40 TB. Die Spezifikationen der von Aurora MySQL unterstützten DB-Instance-Klassen finden Sie unter [Amazon Aurora Aurora-DB-Instance-Klassen](Concepts.DBInstanceClass.md).
**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).
## Maximale Verbindungen zu einer Aurora MySQL-DB-Instance
Die maximale Anzahl der zulässigen Verbindungen mit einer Aurora MySQL-DB-Instance wird durch den Parameter `max_connections` in der Instance-Ebenen-Parametergruppe für die DB-Instance festgelegt.
Die folgende Tabelle listet den Standardwert von `max_connections` für jede DB-Instance auf, die für Aurora MySQL verfügbar ist. Sie können die maximal zulässige Anzahl von Verbindungen mit Ihrer Aurora MySQL-DB-Instance erhöhen, indem Sie die Instance auf eine DB-Instance-Klasse mit mehr Arbeitsspeicher skalieren oder einen größeren Wert für den Parameter `max_connections` in der DB-Parametergruppe für Ihre Instance festlegen, wobei ein Wert von bis zu 16 000 möglich ist.
**Tipp**
Wenn Ihre Anwendungen häufig Verbindungen öffnen und schließen oder langlebige Verbindungen in großer Zahl offen lassen, empfehlen wir Ihnen, Amazon-RDS-Proxy zu verwenden. RDS-Proxy ist ein vollständig verwalteter, hochverfügbarer Datenbank-Proxy, der Datenbankverbindungen sicher und effizient per Verbindungspooling freigibt. Weitere Informationen zu RDS-Proxy finden Sie unter [Amazon RDS-Proxy für Aurora](rds-proxy.md).
Weitere Informationen dazu, wie Aurora Serverless v2-Instances diesen Parameter behandeln, finden Sie unter [Maximale Anzahl der Verbindungen für Aurora Serverless v2](aurora-serverless-v2.setting-capacity.md#aurora-serverless-v2.max-connections).
| Instance class | Vorgabewert max\$1connections |
| --- | --- |
| db.t2.small | 45 |
| db.t2.Medium | 90 |
| db.t3.small | 45 |
| db.t3.medium | 90 |
| db.t3.large | 135 |
| db.t4g.medium | 90 |
| db.t4g.large | 135 |
| db.r3.large | 1000 |
| db.r3.xlarge | 2000 |
| db.r3.2xlarge | 3000 |
| db.r3.4xlarge | 4000 |
| db.r3.8xlarge | 5000 |
| db.r4.large | 1000 |
| db.r4.xlarge | 2000 |
| db.r4.2xlarge | 3000 |
| db.r4.4xlarge | 4000 |
| db.r4.8xlarge | 5000 |
| db.r4.16xlarge | 6 000 |
| db.r5.large | 1000 |
| db.r5.xlarge | 2000 |
| db.r5.2xlarge | 3 000 |
| db.r5.4xlarge | 4000 |
| db.r5.8xlarge | 5000 |
| db.r5.12xlarge | 6 000 |
| db.r5.16xlarge | 6 000 |
| db.r5.24xlarge | 7000 |
| db.r6g.large | 1000 |
| db.r6g.xlarge | 2000 |
| db.r6g.2xlarge | 3 000 |
| db.r6g.4xlarge | 4000 |
| db.r6g.8xlarge | 5000 |
| db.r6g.12xlarge | 6 000 |
| db.r6g.16xlarge | 6 000 |
| db.r6i.large | 1000 |
| db.r6i.xlarge | 2000 |
| db.r6i.2xlarge | 3 000 |
| db.r6i.4xlarge | 4000 |
| db.r6i.8xlarge | 5000 |
| db.r6i.12xlarge | 6 000 |
| db.r6i.16xlarge | 6 000 |
| db.r6i.24xlarge | 7000 |
| db.r6i.32xlarge | 7000 |
| db.r7g.large | 1000 |
| db.r7g.xlarge | 2000 |
| db.r7g.2xlarge | 3 000 |
| db.r7g.4xlarge | 4000 |
| db.r7g.8xlarge | 5000 |
| db.r7g.12xlarge | 6 000 |
| db.r7g.16xlarge | 6 000 |
| db.r7i.large | 1000 |
| db.r7i.xlarge | 2000 |
| db.r7i.2xlarge | 3 000 |
| db.r7i.4xlarge | 4000 |
| db.r7i.8xlarge | 5000 |
| db.r7i.12xlarge | 6 000 |
| db.r7i.16xlarge | 6 000 |
| db.r7i.24xlarge | 7000 |
| db.r7i.48xlarge | 8000 |
| db.r8g.large | 1000 |
| db.r8g.xlarge | 2000 |
| db.r8g.2xlarge | 3 000 |
| db.r8g.4xlarge | 4000 |
| db.r8g.8xlarge | 5000 |
| db.r8g.12xlarge | 6 000 |
| db.r8g.16xlarge | 6 000 |
| db.r8g.24xlarge | 7000 |
| db.r8g.48xlarge | 8000 |
| db.x2g.large | 2000 |
| db.x2g.xlarge | 3 000 |
| db.x2g.2xlarge | 4000 |
| db.x2g.4xlarge | 5000 |
| db.x2g.8xlarge | 6 000 |
| db.x2g.12xlarge | 7000 |
| db.x2g.16xlarge | 7000 |
**Tipp**
Die `max_connections`-Parameterberechnung verwendet die Protokollbasis 2 (unterschiedlich zum natürlichen Logarithmus) und den `DBInstanceClassMemory`-Wert in Byte für die ausgewählte Instance-Klasse von Aurora MySQL. Der Parameter akzeptiert nur Ganzzahlwerte, wobei Dezimalstellen bei Berechnungen gekürzt werden. Die Formel implementiert Verbindungslimits wie folgt:
Inkrement von 1 000 Verbindungen für größere R3-, R4- und R5-Instances
Inkrement von 45 Verbindungen für T2- und T3-Instance-Speichervarianten
Beispiel: Für db.r6g.large berechnet die Formel zwar 1 069,2, das System implementiert aber 1 000, um konsistente inkrementelle Muster aufrechtzuerhalten.
Wenn Sie eine neue Parametergruppe erstellen, um einen eigenen Standardwert für den Verbindungsgrenzwert zu erstellen, werden Sie feststellen, dass der Standard-Verbindungsgrenzwert mithilfe einer auf dem Wert `DBInstanceClassMemory` basierenden Formel abgeleitet wird. Wie in der vorhergehenden Tabelle dargestellt, erzeugt die Formel Verbindungsbegrenzungen, die bei einer Verdoppelung des Speichers über die progressiv größeren R3-, R4- und R5-Instances um jeweils 1000 und bei unterschiedlichen Speichergrößen von T2- und T3-Instances um 45 erhöht werden.
Weitere Informationen darüber, wie `DBInstanceClassMemory` berechnet wird, finden Sie unter [Festlegen von DB-Parametern](USER_ParamValuesRef.md).
Aurora MySQL- und RDS für MySQL-DB-Instances weisen unterschiedliche Speicher-Overhead-Mengen auf. Daher kann der `max_connections`-Wert für Aurora MySQL- und RDS für MySQL-DB-Instances, die dieselbe Instance-Klasse verwenden, unterschiedlich sein. Die Werte in der Tabelle gelten nur für Aurora MySQL-DB-Instances.
**Anmerkung**
Die deutlich niedrigeren Verbindungsgrenzwerte für T2- und T3-Instances basieren darauf, dass diese Instances-Klassen bei Aurora nur für Entwicklungs- und Testszenarien und nicht für Produktionsworkloads vorgesehen sind.
Für Systeme, die Standardwerte für andere größere Arbeitsspeicherverbraucher verwenden, beispielsweise Pufferpool und Abfragezwischenspeicher, werden die Standard-Verbindungsgrenzwerte angepasst. Wenn Sie diese anderen Einstellungen für Ihr Cluster ändern, sollten Sie auch den Verbindungsgrenzwert ändern, um die Zu- oder Abnahme des verfügbaren Arbeitsspeichers in den DB-Instances zu berücksichtigen.
## Temporäre Speicherlimits für Aurora MySQL
Aurora MySQL speichert Tabellen und Indizes im Aurora Speichersubsystem. Aurora MySQL verwendet separaten temporären oder lokalen Speicher für nicht persistente temporäre Dateien und temporäre Nicht-InnoDB-Tabellen. Zum lokalen Speicher gehören auch Dateien, die für Zwecke wie das Sortieren großer Datensätze während der Abfrageverarbeitung oder für Indexerstellungsvorgänge verwendet werden. Er umfasst keine temporären InnoDB-Tabellen.
Weitere Informationen zu temporären Tabellen in Aurora MySQL Version 3 finden Sie unter [Neues temporäres Tabellenverhalten in Aurora-MySQL-Version 3](ams3-temptable-behavior.md). Weitere Informationen zu temporären Tabellen in Version 2 finden Sie unter [Temporäres Tabellenverhalten in Aurora-MySQL-Version 2](AuroraMySQL.CompareMySQL57.md#AuroraMySQL.TempTables57).
Die Daten und temporären Dateien auf diesen Volumes gehen beim Starten und Stoppen der DB-Instance sowie beim Austausch des Hosts verloren.
Diese lokalen Speicher-Volumes werden von Amazon Elastic Block Store (EBS) gestützt und können durch Einsatz einer größeren DB-Instance-Klasse erweitert werden. Weitere Informationen über Speicher finden Sie unter [Amazon Aurora-Speicher](Aurora.Overview.StorageReliability.md).
Lokaler Speicher wird auch für den Import von Daten aus Amazon S3 mit `LOAD DATA FROM S3` oder `LOAD XML FROM S3` und für den Export von Daten zu S3 mit SELECT INTO OUTFILE S3 verwendet. Weitere Informationen zum Import aus und Export zu S3 finden Sie nachfolgend:
+ [Laden von Daten in einen Amazon Aurora MySQL-DB-Cluster aus Textdateien in einem Amazon S3-Bucket](AuroraMySQL.Integrating.LoadFromS3.md)
+ [Speichern von Daten aus einem Amazon Aurora MySQL-DB-Cluster in Textdateien in einem Amazon S3-Bucket](AuroraMySQL.Integrating.SaveIntoS3.md)
Aurora MySQL verwendet separaten permanenten Speicher für Fehlerprotokolle, allgemeine Protokolle, langsame Abfrageprotokolle und Prüfprotokolle für die meisten DB-Instance-Klassen von Aurora MySQL (ausgenommen Instance-Klassentypen mit Spitzenlastleistung wie db.t2, db.t3 und db.t4g). Die Daten auf diesem Volume werden beim Starten und Stoppen der DB-Instance sowie beim Austausch des Hosts beibehalten.
Dieses permanente Speicher-Volume wird ebenfalls von Amazon EBS unterstützt und hat eine feste Größe entsprechend der DB-Instance-Klasse. Eine Erweiterung durch die Verwendung einer größeren DB-Instance-Klasse ist nicht möglich.
Die folgende Tabelle zeigt die maximale Menge an temporärem und permanentem Speicher, die für jede DB-Instance-Klasse von Aurora MySQL verfügbar ist. Informationen zur Unterstützung der DB-Instance-Klasse für Aurora finden Sie unter [Amazon Aurora Aurora-DB-Instance-Klassen](Concepts.DBInstanceClass.md).
| DB-Instance-Klasse (DB instance class) | Maximal verfügbarer temporärer/lokaler Speicher (GiB) | Zusätzlicher maximal verfügbarer Speicher für Protokolldateien (GiB) |
| --- | --- | --- |
| db.x2g.16xlarge | 1280 | 500 |
| db.x2g.12xlarge | 960 | 500 |
| db.x2g.8xlarge | 640 | 500 |
| db.x2g.4xlarge | 320 | 500 |
| db.x2g.2xlarge | 160 | 60 |
| db.x2g.xlarge | 80 | 60 |
| db.x2g.large | 40 | 60 |
| db.r8g.48xlarge | 3840 | 500 |
| db.r8g.24xlarge | 1920 | 500 |
| db.r8g.16xlarge | 1280 | 500 |
| db.r8g.12xlarge | 960 | 500 |
| db.r8g.8xlarge | 640 | 500 |
| db.r8g.4xlarge | 320 | 500 |
| db.r8g.2xlarge | 160 | 60 |
| db.r8g.xlarge | 80 | 60 |
| db.r8g.large | 32 | 60 |
| db.r7i.48xlarge | 3840 | 500 |
| db.r7i.24xlarge | 1920 | 500 |
| db.r7i.16xlarge | 1280 | 500 |
| db.r7i.12xlarge | 960 | 500 |
| db.r7i.8xlarge | 640 | 500 |
| db.r7i.4xlarge | 320 | 500 |
| db.r7i.2xlarge | 160 | 60 |
| db.r7i.xlarge | 80 | 60 |
| db.r7i.large | 32 | 60 |
| db.r7g.16xlarge | 1280 | 500 |
| db.r7g.12xlarge | 960 | 500 |
| db.r7g.8xlarge | 640 | 500 |
| db.r7g.4xlarge | 320 | 500 |
| db.r7g.2xlarge | 160 | 60 |
| db.r7g.xlarge | 80 | 60 |
| db.r7g.large | 32 | 60 |
| db.r6i.32xlarge | 2560 | 500 |
| db.r6i.24xlarge | 1920 | 500 |
| db.r6i.16xlarge | 1280 | 500 |
| db.r6i.12xlarge | 960 | 500 |
| db.r6i.8xlarge | 640 | 500 |
| db.r6i.4xlarge | 320 | 500 |
| db.r6i.2xlarge | 160 | 60 |
| db.r6i.xlarge | 80 | 60 |
| db.r6i.large | 32 | 60 |
| db.r6g.16xlarge | 1280 | 500 |
| db.r6g.12xlarge | 960 | 500 |
| db.r6g.8xlarge | 640 | 500 |
| db.r6g.4xlarge | 320 | 500 |
| db.r6g.2xlarge | 160 | 60 |
| db.r6g.xlarge | 80 | 60 |
| db.r6g.large | 32 | 60 |
| db.r5.24xlarge | 1920 | 500 |
| db.r5.16xlarge | 1280 | 500 |
| db.r5.12xlarge | 960 | 500 |
| db.r5.8xlarge | 640 | 500 |
| db.r5.4xlarge | 320 | 500 |
| db.r5.2xlarge | 160 | 60 |
| db.r5.xlarge | 80 | 60 |
| db.r5.large | 32 | 60 |
| db.r4.16xlarge | 1280 | 500 |
| db.r4.8xlarge | 640 | 500 |
| db.r4.4xlarge | 320 | 500 |
| db.r4.2xlarge | 160 | 60 |
| db.r4.xlarge | 80 | 60 |
| db.r4.large | 32 | 60 |
| db.t4g.large | 32 | – |
| db.t4g.medium | 32 | – |
| db.t3.large | 32 | – |
| db.t3.medium | 32 | – |
| db.t3.small | 32 | – |
| db.t2.medium | 32 | – |
| db.t2.small | 32 | – |
**Wichtig**
Diese Werte stellen die theoretische maximale Menge an freiem Speicher auf jeder DB-Instance dar. Der tatsächliche lokale Speicher, der Ihnen zur Verfügung steht, ist möglicherweise niedriger. Aurora verwendet einen lokalen Speicher für seine Verwaltungsprozesse und die DB-Instance verwendet einen lokalen Speicher, noch bevor Sie Daten laden. Sie können den für eine bestimmte DB-Instance verfügbaren temporären Speicher mit der `FreeLocalStorage`CloudWatch-Metrik überwachen, die unter [CloudWatch Amazon-Metriken für Amazon Aurora](Aurora.AuroraMonitoring.Metrics.md) beschrieben wird. Sie können die Menge des freien Speichers zur Zeit überprüfen. Sie können auch die Menge des freien Speichers im Laufe der Zeit abzeichnen. Die Überwachung des freien Speichers im Laufe der Zeit hilft Ihnen festzustellen, ob der Wert steigt oder sinkt, oder um die Mindest-, Maximal- oder Durchschnittswerte zu ermitteln.
(Dies gilt nicht für Aurora Serverless v2.)
# Rückverfolgen eines Aurora-DB-Clusters
Mit Amazon Aurora MySQL-kompatible Edition können Sie einen DB-Cluster auf einen bestimmten Zeitpunkt zurückverfolgen, ohne die Daten aus einer Sicherung wiederherstellen zu müssen.
**Contents**
+ [Übersicht zur Rückverfolgung](#AuroraMySQL.Managing.Backtrack.Overview)
+ [Rückverfolgungsfenster](#AuroraMySQL.Managing.Backtrack.Overview.BacktrackWindow)
+ [Rückverfolgungszeit](#AuroraMySQL.Managing.Backtrack.Overview.BacktrackTime)
+ [Einschränkungen der Rückverfolgung](#AuroraMySQL.Managing.Backtrack.Limitations)
+ [Verfügbarkeit von Regionen und Versionen](#AuroraMySQL.Managing.Backtrack.Availability)
+ [Überlegungen zum Upgrade für rückverfolgungsfähige Cluster](#AuroraMySQL.Managing.Backtrack.Upgrade)
+ [Konfigurieren der Rückverfolgung eines DB-Clusters von Aurora MySQL](AuroraMySQL.Managing.Backtrack.Configuring.md)
+ [Durchführen einer Rückverfolgung für einen DB-Cluster von Aurora MySQL](AuroraMySQL.Managing.Backtrack.Performing0.md)
+ [Überwachen der Rückverfolgung für einen DB-Cluster von Aurora MySQL](AuroraMySQL.Managing.Backtrack.Monitoring.md)
+ [Abonnieren eines Rückverfolgungsereignisses mit der Konsole](#AuroraMySQL.Managing.Backtrack.Event.Console)
+ [Abrufen vorhandener Rückverfolgungen](#AuroraMySQL.Managing.Backtrack.Retrieving)
+ [Deaktivieren der Rückverfolgung für einen DB-Cluster von Aurora MySQL](AuroraMySQL.Managing.Backtrack.Disabling.md)
## Übersicht zur Rückverfolgung
Durch die Rückverfolgung wird der DB-Cluster auf den angegebenen Zeitpunkt "zurückgespult". Die Rückverfolgung ersetzt nicht das Sichern des DB-Clusters, damit dieser mit dem Stand eines bestimmten Zeitpunkts wiederhergestellt werden kann. Gegenüber herkömmlichen Sicherungen und Wiederherstellungen bietet die Rückverfolgung jedoch einige Vorteile:
+ Sie können Fehler einfach rückgängig machen. Wenn Sie versehentlich eine destruktive Aktion ausführen – beispielsweise eine DELETE-Anweisung ohne WHERE-Klausel –, können Sie den DB-Cluster bei minimaler Unterbrechung der Service-Bereitstellung auf den Zeitpunkt vor der destruktiven Aktion rückverfolgen.
+ Sie können einen DB-Cluster schnell rückverfolgen. Das Wiederherstellen eines DB-Clusters auf den Status eines bestimmten Zeitpunkts startet einen neuen DB-Cluster und stellt diesen aus den Sicherungsdaten oder einem DB-Cluster-Snapshot wieder her. Dies kann einige Stunden dauern. Die Rückverfolgung eines DB-Clusters macht keinen neuen DB-Cluster erforderlich. Zudem erfolgt das "Zurückspulen" innerhalb weniger Minuten.
+ Sie können frühere Datenänderungen untersuchen. Sie können einen DB-Cluster mehrfach in der Zeit zurück- und vorspulen, um zu ermitteln, wann eine bestimmte Datenänderung vorgenommen wurde. Sie können beispielsweise einen DB-Cluster drei Stunden zurück und anschließend eine Stunde vorspulen. In diesem Fall liegt der Rückverfolgungszeitpunkt zwei Stunden vor der Originalzeit.
**Anmerkung**
Weitere Informationen zum Wiederherstellen eines DB-Cluster für einen bestimmten Zeitpunkt finden Sie unter [Übersicht über das Sichern und Wiederherstellen eines Aurora-DB-Clusters](Aurora.Managing.Backups.md).
### Rückverfolgungsfenster
Für die Rückverfolgung gilt ein Zielfenster für die Rückverfolgung und ein Ist-Rückverfolgungsfenster:
+ Das *Zielfenster für die Rückverfolgung* gibt den Zeitraum an, über den die Rückverfolgung des DB-Clusters möglich sein soll. Wenn Sie die Rückverfolgung aktivieren, geben Sie ein *Zielfenster für die Rückverfolgung* an. Sie können beispielsweise ein Zielfenster von 24 Stunden für die Rückverfolgung angeben, wenn die Rückverfolgung des DB-Clusters über einen Tag möglich sein soll.
+ Das *tatsächliche Rückverfolgungsfenster* bezeichnet den tatsächlichen Zeitraum, über den die Rückverfolgung des DB-Clusters möglich ist. Diese Dauer kann kürzer als die des Zielfensters für die Rückverfolgung sein. Das tatsächliche Rückverfolgungsfenster basiert auf dem Workload und dem für Informationen zu Datenbankänderungen (die sogenannten *Änderungsdatensätze*) verfügbaren Arbeitsspeicher.
Wenn Sie ein Aurora-DB-Cluster mit aktivierter Rückverfolgung aktualisieren, generieren Sie Änderungsdatensätze. Aurora bewahrt Änderungsdatensätze für das Zielfenster für die Rückverfolgung auf und Sie zahlen für die Speicherung einen Stundensatz. Die Anzahl gespeicherter Änderungsdatensätze hängt vom Zielfenster für die Rückverfolgung und von der Workload auf dem DB-Cluster ab. Die Workload bezeichnet die Anzahl der Änderungen, die Sie in einem gegebenen Zeitraum am DB-Cluster vornehmen. Bei starker Workload werden mehr Änderungsdatensätze im Zielfenster für die Rückverfolgung gespeichert als bei geringerer Workload.
Das Zielfenster für die Rückverfolgung bezeichnet also die maximale Dauer, über die eine Rückverfolgung des DB-Clusters möglich sein soll. In den meisten Fällen ist eine Rückverfolgung über die von Ihnen angegebene Maximaldauer möglich. In einigen Fällen kann der DB-Cluster aber nicht genug Änderungsdatensätze speichern, um eine Rückverfolgung über diese Maximaldauer zu ermöglichen, das Ist-Rückverfolgungsfenster ist in einer solchen Situation kleiner als das Zielfenster. Normalerweise ist das Ist-Rückverfolgungsfenster kleiner als das Zielfenster, wenn die Workload auf dem DB-Cluster extrem hoch ist. Wenn das Ist-Rückverfolgungsfenster kleiner als das Zielfenster ist, senden wir eine Benachrichtigung.
Wenn die Rückverfolgung für einen DB-Cluster aktiviert ist und Sie eine im DB-Cluster gespeicherte Tabelle löschen, bewahrt Aurora die betreffende Tabelle in den Änderungsdatensätzen für die Rückverfolgung auf. Dies ermöglicht Ihnen die Rückkehr zu einem Zeitpunkt vor dem Löschen der Tabelle. Wenn das Zielfenster für die Rückverfolgung nicht genug Platz zum Speichern der Tabelle bietet, wird die Tabelle schließlich aus den Änderungsdatensätzen für die Rückverfolgung entfernt.
### Rückverfolgungszeit
Die Rückverfolgung durch Aurora erfolgt immer auf einen Zeitpunkt, der für den DB-Cluster konsistent ist. Dadurch wird das Auftreten noch nicht eingetragener Transaktionen nach Abschluss der Rückverfolgung verhindert. Wenn Sie eine Zeit für eine Rückverfolgung angeben, wählt Aurora automatisch den nächstgelegenen konsistenten Zeitpunkt. Dieser Ansatz bedeutet, dass der abgeschlossene Backtrack möglicherweise nicht genau der von Ihnen angegebenen Zeit entspricht, aber Sie können die genaue Zeit für einen Backtrack mithilfe des [describe-db-cluster-backtracks](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-cluster-backtracks.html) AWS CLI-Befehls ermitteln. Weitere Informationen finden Sie unter [Abrufen vorhandener Rückverfolgungen](#AuroraMySQL.Managing.Backtrack.Retrieving).
### Einschränkungen der Rückverfolgung
Die folgenden Einschränkungen gelten für die Rückverfolgung:
+ Die Rückverfolgung ist nur für DB-Cluster verfügbar, die mit aktivierter Rückverfolgungsfunktion erstellt wurden. Sie können einen DB-Cluster nicht modifizieren, um die Rückverfolgungsfunktion zu aktivieren. Sie können die Rückverfolgungsfunktion aktivieren, wenn Sie einen neuen DB-Cluster erstellen oder einen Snapshot eines DB-Clusters wiederherstellen.
+ Die Obergrenze für das Zielfenster für die Rückverfolgung beträgt 72 Stunden.
+ Die Rückverfolgung betrifft den gesamten DB-Cluster. Sie können also beispielsweise nicht eine einzelne Tabelle oder eine einzelne Datenaktualisierung verfolgen.
+ Sie können keine regionsübergreifenden Read Replicas aus einem Cluster mit Rückverfolgungsmöglichkeit erstellen, aber Sie können trotzdem die Replikation von Binärprotokollen (Binlog) auf dem Cluster aktivieren. Wenn Sie versuchen, einen DB-Cluster mit aktivierter Binärprotokollierung rückzuverfolgen, tritt üblicherweise ein Fehler auf, sofern die Rückverfolgung nicht erzwungen wird. Jeder Versuch, einen Backtrack zu erzwingen, macht nachgeschaltete Read Replicas kaputt und beeinträchtigt andere Vorgänge, wie z. B. Bereitstellungen. blue/green
+ Sie können einen Datenbankklon nicht auf einen Zeitpunkt zurückverfolgen, der vor der Erstellung des Datenbankklons liegt. Sie können aber die ursprüngliche Datenbank auf einen Zeitpunkt vor der Erstellung des Klons zurückverfolgen. Weitere Informationen zum Klonen von Datenbanken erhalten Sie unter [Klonen eines Volumes für einen Amazon-Aurora-DB-Cluster](Aurora.Managing.Clone.md).
+ Bei der Rückverfolgung kommt es zu einer kurzen Betriebsunterbrechung der DB-Instance. Sie müssen Anwendungen vor dem Starten einer Rückverfolgung stoppen oder anhalten, um sicherzustellen, dass keine neuen Lese- oder Schreibanforderungen ergehen. Während der Rückverfolgung hält Aurora die Datenbank an, schließt alle offenen Verbindungen und verwirft noch nicht durchgeführte Lese- und Schreibvorgänge. Dann wird der Abschluss der Rückverfolgung abgewartet.
+ Sie können keinen regionsübergreifenden Snapshot eines Clusters mit Backtrack-Aktivierung in einer AWS Region wiederherstellen, die Backtracking nicht unterstützt.
+ Wenn Sie ein direktes Upgrade für einen Cluster mit Rückverfolgungsmöglichkeit von Aurora MySQL Version 2 auf Version 3 durchführen, können Sie nicht auf einen Zeitpunkt vor der Durchführung des Upgrades zurückgehen.
## Verfügbarkeit von Regionen und Versionen
Die Rückverfolgung ist für Aurora PostgreSQL nicht verfügbar.
Im Folgenden sind die unterstützten Engines und die Regionsverfügbarkeit für die Rückverfolgung mit Aurora MySQL aufgeführt.
| Region | Aurora-MySQL-Version 3 | Aurora-MySQL-Version 2 |
| --- | --- | --- |
| USA Ost (Nord-Virginia) | Alle Versionen | Alle Versionen |
| USA Ost (Ohio) | Alle Versionen | Alle Versionen |
| USA West (Nordkalifornien) | Alle Versionen | Alle Versionen |
| USA West (Oregon) | Alle Versionen | Alle Versionen |
| Afrika (Kapstadt) | – | – |
| Asia Pacific (Hongkong) | – | – |
| Asien-Pazifik (Jakarta) | – | – |
| Asien-Pazifik (Malaysia) | – | – |
| Asien-Pazifik (Melbourne) | – | – |
| Asien-Pazifik (Mumbai) | Alle Versionen | Alle Versionen |
| Asien-Pazifik (Neuseeland) | – | – |
| Asien-Pazifik (Osaka) | Alle Versionen | Version 2.07.3 und höher |
| Asien-Pazifik (Seoul) | Alle Versionen | Alle Versionen |
| Asien-Pazifik (Singapur) | Alle Versionen | Alle Versionen |
| Asien-Pazifik (Sydney) | Alle Versionen | Alle Versionen |
| Asien-Pazifik (Taipeh) | – | – |
| Asien-Pazifik (Thailand) | – | – |
| Asien-Pazifik (Tokio) | Alle Versionen | Alle Versionen |
| Kanada (Zentral) | Alle Versionen | Alle Versionen |
| Kanada West (Calgary) | – | – |
| China (Peking) | – | – |
| China (Ningxia) | – | – |
| Europa (Frankfurt) | Alle Versionen | Alle Versionen |
| Europa (Irland) | Alle Versionen | Alle Versionen |
| Europa (London) | Alle Versionen | Alle Versionen |
| Europa (Milan) | – | – |
| Europa (Paris) | Alle Versionen | Alle Versionen |
| Europa (Spain) | – | – |
| Europa (Stockholm) | – | – |
| Europa (Zürich) | – | – |
| Israel (Tel Aviv) | – | – |
| Mexiko (Zentral) | – | – |
| Middle East (Bahrain) | – | – |
| Naher Osten (VAE) | – | – |
| Südamerika (São Paulo) | – | – |
| AWS GovCloud (US-Ost) | – | – |
| AWS GovCloud (US-West) | – | – |
## Überlegungen zum Upgrade für rückverfolgungsfähige Cluster
Sie können ein Upgrade für einen DB-Cluster mit Rückverfolgungsmöglichkeit von Aurora MySQL Version 2 auf Version 3 durchführen, da alle Nebenversionen von Aurora MySQL Version 3 für die Rückverfolgung unterstützt werden.
# Konfigurieren der Rückverfolgung eines DB-Clusters von Aurora MySQL
Um die Rückverfolgungsfunktion zu verwenden, müssen Sie die Rückverfolgung aktivieren und ein Zielfenster für die Rückverfolgung angeben. Andernfalls wird die Rückverfolgung deaktiviert.
Geben Sie für das Zielfenster für die Rückverfolgung an, für wie lange Sie Ihre Datenbank mit dieser Funktion zurückverfolgen können möchten. Aurora versucht, genügend Änderungsaufzeichnungen aufzubewahren, um dieses Zeitfenster zu unterstützen.
## Konsole
Sie können die Konsole verwenden, um die Rückverfolgung beim Erstellen eines DB-Clusters zu konfigurieren. Sie können auch einen DB-Cluster ändern, um das Rückverfolgungsfenster für einen rückverfolgungsfähigen Cluster zu ändern. Wenn Sie die Rückverfolgung für einen Cluster vollständig deaktivieren, indem Sie das Rückverfolgungsfenster auf 0 setzen, können Sie die Rückverfolgung für diesen Cluster nicht erneut aktivieren.
**Topics**
+ [Konfigurieren der Rückverfolgung mit der Konsole beim Erstellen eines DB-Clusters](#AuroraMySQL.Managing.Backtrack.Configuring.Console.Creating)
+ [Konfigurieren der Rückverfolgung mit der Konsole beim Ändern eines DB-Clusters](#AuroraMySQL.Managing.Backtrack.Configuring.Console.Modifying)
### Konfigurieren der Rückverfolgung mit der Konsole beim Erstellen eines DB-Clusters
Wenn Sie ein neues Aurora MySQL-DB-Cluster erstellen, wird die Rückverfolgung konfiguriert, indem Sie **Enable Backtrack (Rückverfolgung aktivieren)** wählen und für **Target Backtrack window (Zielfenster für die Rückverfolgung)** im Bereich **Backtrack (Rückverfolgung)** einen Wert größer als 0 eingeben.
Befolgen Sie die Anweisungen unter , um einen DB-Cluster zu erstelle [Erstellen eines Amazon Aurora-DB Clusters](Aurora.CreateInstance.md). Die folgende Abbildung zeigt den Bereich **Backtrack (Rückverfolgung)**.
![\[Aktivieren der Rückverfolgung beim Erstellen eines DB-Clusters über die Konsole\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/images/aurora-backtrack-create.png)
Wenn Sie einen DB-Cluster erstellen, verfügt Aurora über keinerlei Daten zur Workload des DB-Clusters. Deshalb können die Kosten für den neuen DB-Cluster nicht geschätzt werden. Stattdessen stellt die Konsole einen typischen Wert für die Benutzerkosten für das angegebene Zielfenster für die Rückverfolgung basierend auf einer typischen Workload dar. Diese typischen Kosten dienen also nur als Hinweis auf die möglichen Kosten, die durch die Verwendung der Rückverfolgungsfunktion entstehen können.
**Wichtig**
Ihre tatsächlichen Kosten können niedriger sein, weil sie von der Workload des DB-Clusters abhängig sind.
### Konfigurieren der Rückverfolgung mit der Konsole beim Ändern eines DB-Clusters
Sie können die Rückverfolgung für einen DB-Cluster mit der Konsole ändern.
**Anmerkung**
Derzeit können Sie die Rückverfolgungsfunktion nur für einen DB-Cluster ändern, für den die Funktion „Backtrack“ aktiviert ist. Der Abschnitt **Backtrack** wird nicht für einen DB-Cluster angezeigt, der mit deaktivierter Backtrack-Funktion erstellt wurde oder wenn die Backtrack-Funktion für den DB-Cluster deaktiviert wurde.
**Ändern Sie die Rückverfolgung für einen DB-Cluster mit der Konsole wie folgt:**
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 **Databases (Datenbanken)** aus.
1. Wählen Sie den zu ändernden Cluster und dann die Option **Modify (Ändern)** aus.
1. Ändern Sie für das **Target Backtrack window (Zielfenster für die Rückverfolgung)** den Zeitraum, über den die Rückverfolgung möglich sein soll. Die Obergrenze ist 72 Stunden.
![\[Ändern der Rückverfolgung über die Konsole\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/images/aurora-backtrack-modify.png)
Die Konsole zeigt die geschätzten Kosten für die von Ihnen angegebene Größe des Zeitfensters basierend auf der Workload des DB-Clusters in der Vergangenheit an:
+ Wenn Backtracking auf dem DB-Cluster deaktiviert war, basiert die Kostenschätzung auf der `VolumeWriteIOPS` Metrik für den DB-Cluster in Amazon CloudWatch.
+ Wenn Backtracking zuvor auf dem DB-Cluster aktiviert war, basiert die Kostenschätzung auf der `BacktrackChangeRecordsCreationRate` Metrik für den DB-Cluster in Amazon CloudWatch.
1. Klicken Sie auf **Weiter**.
1. Wählen Sie für **Einplanung von Änderungen** eine der folgenden Optionen:
+ **Apply during the next scheduled maintenance window (Im nächsten geplanten Wartungsfenster anwenden)**: Die Änderung für **Target Backtrack window (Zielfenster für die Rückverfolgung)** soll erst im nächsten Wartungsfenster angewendet werden.
+ **Apply immediately (Sofort anwenden)**: Die Änderung für **Target Backtrack window (Zielfenster für die Rückverfolgung)** soll so bald wie möglich angewendet werden.
1. Wählen Sie **Modify Cluster (Cluster ändern)** aus.
## AWS CLI
Wenn Sie mit dem [create-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-cluster.html) AWS CLI-Befehl einen neuen Aurora MySQL-DB-Cluster erstellen, wird Backtracking konfiguriert, wenn Sie einen `--backtrack-window` Wert angeben, der größer als Null ist. Der Wert `--backtrack-window` gibt das Zielfenster für die Rückverfolgung an. Weitere Informationen finden Sie unter [Erstellen eines Amazon Aurora-DB Clusters](Aurora.CreateInstance.md).
Sie können den `--backtrack-window` Wert auch mit den folgenden AWS CLI-Befehlen angeben:
+ [modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html)
+ [restore-db-cluster-from-s3](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-cluster-from-s3.html)
+ [restore-db-cluster-from-Schnappschuss](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-cluster-from-snapshot.html)
+ [restore-db-cluster-to-point-in-time](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-cluster-to-point-in-time.html)
Das folgende Verfahren beschreibt, wie Sie das Zielfenster für die Rückverfolgung für einen DB-Cluster mit der änder AWS CLI.
**Um das Ziel-Backtrack-Fenster für einen DB-Cluster zu ändern, verwenden Sie AWS CLI**
+ Rufen Sie den [modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html) AWS CLI-Befehl auf und geben Sie die folgenden Werte an:
+ `--db-cluster-identifier`: Name des DB-Clusters.
+ `--backtrack-window`: maximaler Zeitraum in Sekunden für die Rückverfolgung des DB-Clusters.
Im folgenden Beispiel wird für das Zielfenster für die Rückverfolgung von `sample-cluster` ein Wert von einem Tag (86 400 Sekunden) festgelegt.
Für Linux, macOS oder Unix:
```
aws rds modify-db-cluster \
--db-cluster-identifier sample-cluster \
--backtrack-window 86400
```
Für Windows:
```
aws rds modify-db-cluster ^
--db-cluster-identifier sample-cluster ^
--backtrack-window 86400
```
**Anmerkung**
Derzeit kann die Rückverfolgung nur für einen DB-Cluster aktiviert werden, der mit aktivierter Rückverfolgungsfunktion erstellt wurde.
## RDS-API
Wenn Sie mit dem Vorgang Create DBCluster Amazon RDS API einen neuen Aurora MySQL-DB-Cluster [erstellen](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBCluster.html), wird Backtracking konfiguriert, wenn Sie einen `BacktrackWindow` Wert angeben, der größer als Null ist. Der Wert `BacktrackWindow` gibt das Zielfenster für die Rückverfolgung für den mit dem Wert `DBClusterIdentifier` angegebenen DB-Cluster an. Weitere Informationen finden Sie unter [Erstellen eines Amazon Aurora-DB Clusters](Aurora.CreateInstance.md).
Sie können den Wert für `BacktrackWindow` auch mittels der folgenden API-Operationen angeben:
+ [Modifizieren SieDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html)
+ [Aus S3 wiederherstellen DBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBClusterFromS3.html)
+ [WiederherstellungDBClusterFromSnapshot](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBClusterFromSnapshot.html)
+ [WiederherstellungDBClusterToPointInTime](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBClusterToPointInTime.html)
**Anmerkung**
Derzeit kann die Rückverfolgung nur für einen DB-Cluster aktiviert werden, der mit aktivierter Rückverfolgungsfunktion erstellt wurde.
# Durchführen einer Rückverfolgung für einen DB-Cluster von Aurora MySQL
Sie können einen DB-Cluster auf einen bestimmten Zeitpunkt im Zielfenster für die Rückverfolgung rückverfolgen. Wenn der Zeitstempel für die Rückverfolgung nicht vor dem frühestmöglichen Rückverfolgungszeitpunkt und auch nicht in der Zukunft liegt, wird der DB-Cluster auf den betreffenden Zeitpunkt rückverfolgt.
Andernfalls tritt üblicherweise ein Fehler auf. Wenn Sie versuchen, einen DB-Cluster mit aktivierter Binärprotokollierung rückzuverfolgen, tritt üblicherweise ein Fehler auf, sofern Sie nicht das Erzwingen der Rückverfolgung veranlasst haben. Das Erzwingen einer Rückverfolgung kann zu Problemen mit anderen Operationen führen, die Binärprotokollierung verwenden.
**Wichtig**
Die Rückverfolgung erzeugt keine binlog-Einträge für die von der Funktion vorgenommenen Änderungen. Wenn Sie die Binärprotokollierung für den DB-Cluster aktiviert haben, ist die Rückverfolgung möglicherweise nicht mit der binlog-Implementierung kompatibel.
**Anmerkung**
Bei Datenbankklonen können Sie den DB-Cluster auf einen Zeitpunkt rückverfolgen, der vor dem Zeitpunkt der Erstellung des Klons liegt. Weitere Informationen zum Klonen von Datenbanken erhalten Sie unter [Klonen eines Volumes für einen Amazon-Aurora-DB-Cluster](Aurora.Managing.Clone.md).
## Konsole
Das folgende Verfahren beschreibt, wie Sie eine Rückverfolgung für einen DB-Cluster mit der Konsole durchführen.
**Führen Sie eine Rückverfolgung mit der Konsole wie folgt durch:**
1. Melden Sie sich bei der AWS-Managementkonsole an 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 **Instances** aus.
1. Wählen Sie die primäre Instance für den DB-Cluster aus, den Sie rückverfolgen möchten.
1. Wählen Sie unter **Actions (Aktionen)** die Option **Backtrack DB cluster (DB-Cluster rückverfolgen)** aus.
1. Geben Sie auf der Seite **Backtrack DB cluster (DB-Cluster rückverfolgen)** den Zeitstempel ein, zu dem der DB-Cluster rückverfolgt werden soll.
![\[Backtrack DB cluster (DB-Cluster rückverfolgen)\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/images/aurora-backtrack-db-cluster.png)
1. Wählen Sie **Backtrack DB cluster (DB-Cluster rückverfolgen)** aus.
## AWS CLI
Im folgenden Verfahren wird beschrieben, wie ein DB-Cluster mit der rückverfolgt wir AWS CLI.
**Rückverfolgen Sie einen DB-Cluster mit der wie folgt AWS CLI**
+ Rufen Sie den AWS-CLI-Befehl [backtrack-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/backtrack-db-cluster.html) auf und stellen Sie die folgenden Werte bereit:
+ `--db-cluster-identifier`: Name des DB-Clusters.
+ `--backtrack-to` – Der Zeitstempel im ISO 8601-Format, zu dem das DB-Cluster zurückverfolgt werden soll.
Das folgende Beispiel führt eine Rückverfolgung des DB-Clusters `sample-cluster` auf den 19. März 2018 um 10:00 Uhr durch.
Für Linux, macOS oder Unix:
```
aws rds backtrack-db-cluster \
--db-cluster-identifier sample-cluster \
--backtrack-to 2018-03-19T10:00:00+00:00
```
Für Windows:
```
aws rds backtrack-db-cluster ^
--db-cluster-identifier sample-cluster ^
--backtrack-to 2018-03-19T10:00:00+00:00
```
## RDS-API
Um ein DB-Cluster über die Amazon-RDS-API zurückzuverfolgen, verwenden Sie die Operation [BacktrackDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_BacktrackDBCluster.html). Diese Operation nimmt die Rückverfolgung des mit `DBClusterIdentifier` angegebenen DB-Clusters auf den angegebenen Zeitpunkt vor.
# Überwachen der Rückverfolgung für einen DB-Cluster von Aurora MySQL
Sie können Rückverfolgungsinformationen für einen DB-Cluster anzeigen sowie Rückverfolgungskennzahlen überwachen.
## Konsole
**Zeigen Sie mit der Konsole Rückverfolgungsinformationen für einen DB-Cluster an und überwachen Sie die Rückverfolgungskennzahlen wie folgt:**
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 **Databases (Datenbanken)** aus.
1. Wählen Sie den Namen des DB-Clusters, um die zugehörigen Informationen anzuzeigen.
Die Rückverfolgungsinformationen befinden sich im Bereich **Backtrack (Rückverfolgung)**.
![\[Rückverfolgungsdetails für ein DB-Cluster\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/images/aurora-backtrack-details.png)
Wenn die Rückverfolgung aktiviert ist, sind folgende Informationen verfügbar:
+ **Target window (Zielfenster)**: der zurzeit für das Zielfenster für die Rückverfolgung angegebene Zeitraum. Das Zielfenster bezeichnet die maximale Dauer, für die eine Rückverfolgung durchgeführt werden kann, sofern genug Speicher verfügbar ist.
+ **Actual window (Tatsächliches Fenster)**: der tatsächliche Zeitraum, über den Sie die Rückverfolgung ausführen können; dieser kann kleiner als das Zielfenster für die Rückverfolgung sein. Das Ist-Rückverfolgungsfenster basiert auf der Workload und dem für die Aufnahme von Änderungsdatensätzen für die Rückverfolgung verfügbaren Speicher.
+ **Earliest backtrack time (Früheste Rückverfolgungszeit)**: der früheste Rückverfolgungszeitpunkt, der für das DB-Cluster möglich ist. Sie können einen DB-Cluster nicht auf eine vor dem angezeigten Zeitpunkt liegende Zeit rückverfolgen.
1. Zeigen Sie die Rückverfolgungskennzahlen für den DB-Cluster wie folgt an:
1. Wählen Sie im Navigationsbereich **Instances** aus.
1. Wählen Sie den Namen der primären Instance des DB-Clusters, um die Details anzuzeigen.
1. Geben Sie im **CloudWatch**Abschnitt etwas **Backtrack** in das **CloudWatch**Feld ein, um nur die Backtrack-Metriken anzuzeigen.
![\[Rückverfolgungsmetriken\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/images/aurora-backtrack-metrics.png)
Die folgenden Kennzahlen werden angezeigt:
+ **Backtrack Change Records Creation Rate (Count) (Erstellungsrate (Anzahl) der Änderungsdatensätze für die Rückverfolgung)**: Diese Metrik gibt die Anzahl der Änderungsdatensätze für die Rückverfolgung an, die im Verlauf von fünf Minuten für das DB-Cluster erstellt wurden. Sie können diese Kennzahl heranziehen, um die Rückverfolgungskosten für das Zielfenster für die Rückverfolgung zu schätzen.
+ **[Billed] Backtrack Change Records Stored (Count) ([Berechnete] für die Rückverfolgung gespeicherte Änderungsdatensätze (Anzahl))**: Diese Metrik gibt die tatsächliche Anzahl der Änderungsdatensätze für die Rückverfolgung an, die vom DB-Cluster verwendet werden.
+ **Backtrack Window Actual (Minutes) (Tatsächliches Rückverfolgungsfenster (Minuten))**: Diese Metrik gibt an, ob es eine Differenz zwischen dem Zielfenster für die Rückverfolgung und dem tatsächlichen Rückverfolgungsfenster gibt. Wenn das Zielfenster für die Rückverfolgung beispielsweise 2 Stunden (120 Minuten) lang ist und diese Kennzahl angibt, dass das Ist-Rückverfolgungsfenster nur 100 Minuten lang ist, ist das Ist-Rückverfolgungsfenster kleiner als das Zielfenster.
+ **Backtrack Window Alert (Count) (Rückverfolgungsfenster-Alarm (Anzahl))**: Diese Metrik gibt an, wie oft das tatsächliche Rückverfolgungsfenster über einen bestimmten Zeitraum kleiner als das Zielfenster für die Rückverfolgung ist.
**Anmerkung**
Die folgenden Kennzahlen können hinter der aktuellen Zeit zurückliegen:
**Erstellungsrate (Anzahl) der Änderungsdatensätze für die Rückverfolgung**
**[Billed] Backtrack Change Records Stored (Count) ([Berechnete] für die Rückverfolgung gespeicherte Änderungsdatensätze (Anzahl))**
## AWS CLI
Das folgende Verfahren beschreibt, wie Sie Rückverfolgungsinformationen für einen DB-Cluster mit anzeige AWS CLI.
**Um Backtrack-Informationen für einen DB-Cluster anzuzeigen, verwenden Sie AWS CLI**
+ Rufen Sie den [describe-db-clusters](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-clusters.html) AWS CLI-Befehl auf und geben Sie die folgenden Werte an:
+ `--db-cluster-identifier`: Name des DB-Clusters.
Das folgende Beispiel listet Rückverfolgungsinformationen für au `sample-cluster`.
Für Linux, macOS oder Unix:
```
aws rds describe-db-clusters \
--db-cluster-identifier sample-cluster
```
Für Windows:
```
aws rds describe-db-clusters ^
--db-cluster-identifier sample-cluster
```
## RDS-API
Verwenden Sie den DBClusters Vorgang [Describe](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBClusters.html), um Backtrack-Informationen für einen DB-Cluster mithilfe der Amazon RDS-API anzuzeigen. Diese Operation gibt Rückverfolgungsinformationen für den mit dem Wert `DBClusterIdentifier` angegebenen DB-Cluster zurück.
## Abonnieren eines Rückverfolgungsereignisses mit der Konsole
Das folgende Verfahren beschreibt, wie Sie ein Rückverfolgungsereignis mit der Konsole abonnieren. Das Ereignis sendet eine E-Mail oder SMS, wenn das Ist-Rückverfolgungsfenster kürzer als das Zielfenster für die Rückverfolgung ist.
**Zeigen Sie Rückverfolgungsinformationen mit der Konsole wie folgt 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 **Event subscriptions (Ereignisabonnements)** aus.
1. Wählen Sie **Create event subscription (Ereignisabonnement erstellen)** aus.
1. Geben Sie in das Feld **Name (Name)** einen Namen für das Ereignisabonnement ein und stellen Sie sicher, dass für **Enabled (Aktiviert)** der Wert **Yes (Ja)** ausgewählt ist.
1. Wählen Sie im Bereich **Target (Ziel)** die Option **New email topic (Neues E-Mail-Thema)** aus.
1. Geben Sie unter **Topic name (Themenname)** einen Namen für das Thema und unter **With these recipients (Mit diesen Empfängern)** die E-Mail-Adressen oder Telefonnummern der Benachrichtigungsempfänger ein.
1. Wählen Sie im Bereich **Source (Quelle)** für **Source type (Quellentyp)** den Wert **Instances (Instances)** aus.
1. Wählen Sie für **Instances to include (Einzuschließende Instances)** den Wert **Select specific instances (Bestimmte Instances auswählen)** und dann die DB-Instance aus.
1. Wählen Sie für **Event categories to include (Einzuschließende Ereigniskategorien)** den Wert **Select specific event categories (Bestimmte Ereigniskategorien auswählen)** und dann **Backtrack (Rückverfolgen)** aus.
Die Seite sollte der folgenden Seite ähneln.
![\[Rückverfolgungsereignis-Abonnement\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/images/aurora-backtrack-event.png)
1. Wählen Sie **Create** aus.
## Abrufen vorhandener Rückverfolgungen
Sie können Informationen über existierende Rückverfolgungen für einen DB-Cluster abrufen. Zu diesen Informationen gehören die eindeutige ID der Rückverfolgung, Ausgangs- und Zielzeitpunkt der Rückverfolgung, Datum und Zeitpunkt der Anforderung der Rückverfolgung und der aktuelle Status der Rückverfolgung.
**Anmerkung**
Derzeit können vorhandene Rückverfolgungen nicht mit der Konsole abgerufen werden.
### AWS CLI
Das folgende Verfahren beschreibt, wie Sie vorhandene Rückverfolgungen für einen DB-Cluster mit der abrufe AWS CLI.
**Um vorhandene Backtracks mit dem abzurufen AWS CLI**
+ Rufen Sie den [describe-db-cluster-backtracks](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-cluster-backtracks.html) AWS CLI-Befehl auf und geben Sie die folgenden Werte an:
+ `--db-cluster-identifier`: Name des DB-Clusters.
Im folgenden Beispiel werden die für vorhandenen Rückverfolgungen abgerufe `sample-cluster`.
Für Linux, macOS oder Unix:
```
aws rds describe-db-cluster-backtracks \
--db-cluster-identifier sample-cluster
```
Für Windows:
```
aws rds describe-db-cluster-backtracks ^
--db-cluster-identifier sample-cluster
```
### RDS-API
Um Informationen über die Backtracks für einen DB-Cluster mithilfe der Amazon RDS-API abzurufen, verwenden Sie den Vorgang [Describe DBCluster Backtracks](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBClusterBacktracks.html). Diese Operation gibt Informationen über Rückverfolgungen für den mit dem Wert `DBClusterIdentifier` angegebenen DB-Cluster zurück.
# Deaktivieren der Rückverfolgung für einen DB-Cluster von Aurora MySQL
Sie können die Rückverfolgungsfunktion für einen DB-Cluster deaktivieren.
## Konsole
Sie können die Rückverfolgung für einen DB-Cluster mit der Konsole deaktivieren. Nachdem Sie die Rückverfolgung für einen Cluster vollständig deaktiviert haben, können Sie sie für diesen Cluster nicht erneut aktivieren.
**Deaktivieren Sie die Rückverfolgungsfunktion für einen DB-Cluster mit der Konsole wie folgt:**
1. Melden Sie sich bei der AWS-Managementkonsole an und öffnen Sie die Amazon-RDS-Konsole unter [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Wählen Sie **Databases (Datenbanken)** aus.
1. Wählen Sie den zu ändernden Cluster und dann die Option **Modify (Ändern)** aus.
1. Wählen Sie im Bereich **Backtrack (Rückverfolgung)** die Option **Disable Backtrack (Rückverfolgung deaktivieren)** aus.
1. Klicken Sie auf **Weiter**.
1. Wählen Sie für **Einplanung von Änderungen** eine der folgenden Optionen:
+ **Apply during the next scheduled maintenance window (Während des nächsten geplanten Wartungsfensters anwenden)**: Die Änderung soll erst während des nächsten Wartungsfensters ausgeführt werden.
+ **Apply immediately (Sofort anwenden)**: Die Änderung soll sobald wie möglich angewendet werden.
1. Wählen Sie **Modify Cluster (Cluster ändern)** aus.
## AWS CLI
Sie können die Rückverfolgungsfunktion für ein DB-Cluster über die AWS CLI deaktivieren, indem Sie das Zielfenster für die Rückverfolgung auf `0` (null) festlegen. Nachdem Sie die Rückverfolgung für einen Cluster vollständig deaktiviert haben, können Sie sie für diesen Cluster nicht erneut aktivieren.
**Ändern Sie das Zeitfenster für die Rückverfolgung für einen DB-Cluster mit der wie folgt 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 folgende Werte an:
+ `--db-cluster-identifier`: Name des DB-Clusters.
+ `--backtrack-window` – Geben Sie `0` an, um die Rückverfolgung zu deaktivieren.
Im folgenden Beispiel wird die Rückverfolgungsfunktion für `sample-cluster` deaktiviert, indem `--backtrack-window` der Wert `0` zugewiesen wird.
Für Linux, macOS oder Unix:
```
aws rds modify-db-cluster \
--db-cluster-identifier sample-cluster \
--backtrack-window 0
```
Für Windows:
```
aws rds modify-db-cluster ^
--db-cluster-identifier sample-cluster ^
--backtrack-window 0
```
## RDS-API
Um die Rückverfolgungsfunktion für einen DB-Cluster über die Amazon-RDS-API zu deaktivieren, verwenden Sie die Aktion [ModifyDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html). Weisen Sie `BacktrackWindow` den Wert `0` (Null) zu und geben Sie den DB-Cluster im Wert `DBClusterIdentifier` an. Nachdem Sie die Rückverfolgung für einen Cluster vollständig deaktiviert haben, können Sie sie für diesen Cluster nicht erneut aktivieren.
# Testen von Amazon Aurora MySQL unter Verwendung von Fehlersimulationsabfragen
Sie können die Fehlertoleranz Ihres DB-Clusters von Aurora MySQL testen, indem Sie Fehlersimulationsabfragen verwenden. Fehlersimulationsabfragen werden als SQL-Befehle an eine Amazon Aurora-Instance ausgegeben. Sie ermöglichen Ihnen, eines der folgenden Fehlerereignisse geplant zu simulieren:
+ Einen Ausfall einer Writer- oder Reader-DB-Instance
+ Ein Ausfall eines Aurora-Replikats
+ Einen Festplattenfehler
+ Festplattenüberlastung
Wenn eine Fehlersimulationsabfrage einen Absturz angibt, erzwingt sie einen Absturz der DB-Instance von Aurora MySQL. Die anderen Fehler-Injection-Abfragen erzeugen Simulationen von Ausfallereignissen, lösen aber keine Ereignisse aus. Wenn Sie eine Fehlersimulationsabfrage senden, geben Sie auch einen Zeitraum vor, in dem die Simulation ablaufen soll.
Sie können eine Fehlersimulationsabfrage an eine Ihrer Aurora Replica-Instances senden, indem Sie eine Verbindung mit dem Endpunkt der Aurora Replica herstellen. Weitere Informationen finden Sie unter [Amazon-Aurora-Endpunktverbindungen](Aurora.Overview.Endpoints.md).
Zum Ausführen von Fehlersimulationsabfragen sind alle Master-Benutzerrechte erforderlich. Weitere Informationen finden Sie unter [Berechtigungen von Hauptbenutzerkonten](UsingWithRDS.MasterAccounts.md).
## Testen eines Instance-Ausfalls
Sie können den Absturz einer Amazon-Aurora-Instance erzwingen, indem Sie die Fehlersimulationsabfrage `ALTER SYSTEM CRASH` verwenden.
Für diese Fehlersimulationsabfrage tritt kein Failover auf. Wenn Sie einen Failover testen möchten, können Sie die **Failover-Instance-Aktion** für Ihren DB-Cluster in der RDS-Konsole auswählen oder den [failover-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/failover-db-cluster.html) AWS CLI Befehl oder den [DBClusterFailover-RDS-API-Vorgang](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_FailoverDBCluster.html) verwenden.
### Syntax
```
1. ALTER SYSTEM CRASH [ INSTANCE | DISPATCHER | NODE ];
```
### Optionen
Diese Fehlersimulationsabfrage löst einen der folgenden Ausfalltypen aus:
+ **`INSTANCE`** – Es wird ein Absturz der PostgreSQL-kompatiblen Datenbank für die Amazon-Aurora-Instance simuliert.
+ **`DISPATCHER`** – Es wird ein Absturz des Dispatchers auf Schreiber-Instance für das Aurora-DB-Cluster simuliert. Der *Dispatcher* schreibt Updates zum Cluster-Volume für ein Amazon Aurora-DB-Cluster.
+ **`NODE`** – Es wird ein Absturz sowohl der MySQL-kompatiblen Datenbank als auch des Dispatchers für die Amazon-Aurora-Instance simuliert. Für diese Fehlersimulationsabfrage wird auch der Cache gelöscht.
Der Standard-Ausfalltyp ist `INSTANCE`.
## Testen eines Aurora-Replikatausfalls
Sie können den Ausfall eines Aurora-Replikats mittels der Fehlersimulationsabfrage `ALTER SYSTEM SIMULATE READ REPLICA FAILURE` simulieren.
Der Ausfall eines Aurora Replica blockiert alle Anfragen an einen Aurora Replica oder alle Aurora Replicas im DB-Cluster für einen bestimmten Zeitabschnitt. Wenn dieser abgelaufen ist, werden die betroffenen Aurora-Replikate automatisch mit der Schreiber-Instance synchronisiert.
### Syntax
```
1. ALTER SYSTEM SIMULATE percentage_of_failure PERCENT READ REPLICA FAILURE
2. [ TO ALL | TO "replica name" ]
3. FOR INTERVAL quantity { YEAR | QUARTER | MONTH | WEEK | DAY | HOUR | MINUTE | SECOND };
```
### Optionen
Diese Fehlersimulationsabfrage verwendet die folgenden Parameter:
+ **`percentage_of_failure`** – Der Prozentsatz der Anfragen, die während des Ausfallereignisses blockiert werden sollen. Dieser Wert kann ein Duplikat zwischen 0 und 100 sein. Wenn Sie 0 festlegen, werden keine Anfragen blockiert. Wenn 100 festgelegt wird, werden alle Anfragen blockiert.
+ **Ausfalltyp** – Der zu simulierende Ausfalltyp. Legen Sie `TO ALL` fest, um Ausfälle für alle Aurora-Replikate im DB-Cluster zu simulieren. Geben Sie `TO` und den Namen eines Aurora-Replikats an, um einen Ausfall des einzelnen Aurora-Replikats zu simulieren. Der Standard-Ausfalltyp ist `TO ALL`.
+ **`quantity`** – Der Zeitraum, über den der Ausfall des Aurora-Replikats simuliert werden soll. Das Intervall wird als eine Menge gefolgt von einer Zeiteinheit angegeben. Die Simulation wird für die Dauer der angegebenen Einheit auftreten. Beispielsweise ergibt `20 MINUTE` eine Simulation, die 20 Minuten lang ausgeführt wird.
**Anmerkung**
Seien Sie vorsichtig bei der Angabe des Zeitintervalls für das Ausfallereignis in Ihrem Aurora-Replikat. Wenn Sie ein zu langes Zeitintervall festlegen und Ihre Schreiber-Instance eine große Datenmenge während des Ausfallereignisses schreibt, könnte Ihr Aurora-DB-Cluster annehmen, dass Ihr Aurora-Replikat ausgefallen ist und es ersetzen.
## Testen eines Festplattenausfalls
Sie können einen Datenträgerausfall für ein Aurora-DB-Cluster mittels der Fehlersimulationsabfrage `ALTER SYSTEM SIMULATE DISK FAILURE` simulieren.
Während einer Simulation eines Festplattenausfalls markiert der Aurora-DB-Cluster zufällige Festplattensegmente als fehlerhaft. Anfragen an diese Segmente werden für die Dauer der Simulation blockiert.
### Syntax
```
1. ALTER SYSTEM SIMULATE percentage_of_failure PERCENT DISK FAILURE
2. [ IN DISK index | NODE index ]
3. FOR INTERVAL quantity { YEAR | QUARTER | MONTH | WEEK | DAY | HOUR | MINUTE | SECOND };
```
### Optionen
Diese Fehlersimulationsabfrage verwendet die folgenden Parameter:
+ **`percentage_of_failure`** – Der Prozentsatz des Datenträgers, der während des Ausfallereignisses als ausgefallen markiert werden soll. Dieser Wert kann ein Duplikat zwischen 0 und 100 sein. Wenn Sie 0 festlegen, wird kein Segment der Festplatte als fehlerhaft markiert. Wenn Sie 100 festlegen, wird die gesamte Festplatte als fehlerhaft markiert.
+ **`DISK index`** – Ein spezifischer logischer Datenblock, für den das Ausfallereignis simuliert werden soll. Wenn Sie den verfügbaren Bereich an logischen Datenblocks überschreiten, erhalten Sie eine Fehlermeldung, in der Ihnen der maximal festlegbare Indexwert mitgeteilt wird. Weitere Informationen finden Sie unter [Anzeigen des Volume-Status für einen Aurora MySQL-DB-Cluster](AuroraMySQL.Managing.VolumeStatus.md).
+ **`NODE index`** – Ein spezifischer Speicherknoten, für den das Ausfallereignis simuliert werden soll. Wenn Sie den verfügbaren Bereich an Speicherknoten überschreiten, erhalten Sie eine Fehlermeldung, in der Ihnen der maximal festlegbare Indexwert mitgeteilt wird. Weitere Informationen finden Sie unter [Anzeigen des Volume-Status für einen Aurora MySQL-DB-Cluster](AuroraMySQL.Managing.VolumeStatus.md).
+ **`quantity`** – Der Zeitraum, über den der Datenträgerausfall simuliert werden soll. Das Intervall wird als eine Menge gefolgt von einer Zeiteinheit angegeben. Die Simulation wird für die Dauer der angegebenen Einheit auftreten. Beispielsweise ergibt `20 MINUTE` eine Simulation, die 20 Minuten lang ausgeführt wird.
## Testen einer Festplattenüberlastung
Sie können einen Datenträgerausfall für ein Aurora-DB-Cluster mittels der Fehlersimulationsabfrage `ALTER SYSTEM SIMULATE DISK CONGESTION` simulieren.
Während einer Simulation einer Festplattenüberlastung markiert der Aurora-DB-Cluster zufällige Festplattensegmente als überlastet. Anfragen an diese Segmente werden für die Dauer der angegebenen minimalen und maximalen Verzögerungszeit während der Simulation verzögert.
### Syntax
```
1. ALTER SYSTEM SIMULATE percentage_of_failure PERCENT DISK CONGESTION
2. BETWEEN minimum AND maximum MILLISECONDS
3. [ IN DISK index | NODE index ]
4. FOR INTERVAL quantity { YEAR | QUARTER | MONTH | WEEK | DAY | HOUR | MINUTE | SECOND };
```
### Optionen
Diese Fehlersimulationsabfrage verwendet die folgenden Parameter:
+ **`percentage_of_failure`** – Der Prozentsatz des Datenträgers, der während des Ausfallereignisses als überlastet markiert werden soll. Dieser Wert kann ein Duplikat zwischen 0 und 100 sein. Wenn Sie 0 festlegen, wird kein Segment der Festplatte als überlastet markiert. Wenn Sie 100 festlegen, wird die gesamte Festplatte als überlastet markiert.
+ **`DISK index` oder `NODE index`** – Ein spezifischer Datenträger oder Knoten, für den das Ausfallereignis simuliert werden soll. Wenn Sie den verfügbaren Bereich der Indizes für die Festplatten oder den Knoten überschreiten, erhalten Sie eine Fehlermeldung, in der Ihnen der maximal festlegbare Indexwert mitgeteilt wird.
+ **`minimum` und `maximum`** – Der Mindest- und Höchstwert in Millisekunden für die Überlastungsverzögerung. Festplattensegmente, die als überlastet markiert sind, werden innerhalb des Bereichs zwischen der minimalen und maximalen Anzahl an Millisekunden während der Simulation verzögert.
+ **`quantity`** – Der Zeitraum, über den die Datenträgerüberlastung simuliert werden soll. Das Intervall wird als eine Menge gefolgt von einer Zeiteinheit angegeben. Die Simulation wird für die Dauer der angegebenen Zeiteinheit ausgeführt. Beispielsweise ergibt `20 MINUTE` eine Simulation, die 20 Minuten lang ausgeführt wird.
# Ändern von Tabellen in Amazon Aurora mithilfe von Fast DDL
Amazon Aurora umfasst Optimierungen, um einen `ALTER TABLE`-Vorgang nahezu sofort auszuführen. Der Vorgang schließt ab, ohne dass ein Kopieren der Tabelle erforderlich ist und ohne eine materielle Auswirkung auf andere DML-Statements zu haben. Da kein temporärer Speicher für eine Tabellenkopie benötigt wird, haben DDL-Statements praktische Vorteile, sogar für große Tabellen auf kleinen Instance-Klassen.
Aurora MySQL Version 3 ist mit der MySQL 8.0-Funktion namens Instant DDL kompatibel. Aurora MySQL Version 2 verwendet eine andere Implementierung namens Fast DDL.
**Topics**
+ [Sofortige DDL (Aurora MySQL Version 3)](#AuroraMySQL.mysql80-instant-ddl)
+ [Fast DDL (Aurora MySQL Version 2)](#AuroraMySQL.Managing.FastDDL-v2)
## Sofortige DDL (Aurora MySQL Version 3)
Die von Aurora MySQL Version 3 durchgeführte Optimierung zur Verbesserung der Effizienz einiger DDL-Vorgänge wird als Instant DDL bezeichnet.
Aurora MySQL Version 3 ist mit der Instant DDL von Community MySQL 8.0 kompatibel. Sie führen einen sofortigen DDL-Vorgang durch, indem Sie die Klausel `ALGORITHM=INSTANT` mit der `ALTER TABLE`-Anweisung verwenden. Weitere Informationen zu Syntax und Verwendung von Instant DDL finden Sie unter [ALTER TABLE](https://dev.mysql.com/doc/refman/8.0/en/alter-table.html) und [Online DDL Operations](https://dev.mysql.com/doc/refman/8.0/en/innodb-online-ddl-operations.html) in der MySQL-Dokumentation.
Die folgenden Beispiele veranschaulichen die Instant-DDL-Funktion. Die `ALTER TABLE`-Anweisungen fügen Spalten hinzu und ändern die Standardspaltenwerte. Die Beispiele umfassen sowohl reguläre als auch virtuelle Spalten sowie reguläre und partitionierte Tabellen. Bei jedem Schritt können Sie die Ergebnisse durch die Ausgabe von `SHOW CREATE TABLE`- und `DESCRIBE`-Anweisungen anzeigen.
```
mysql> CREATE TABLE t1 (a INT, b INT, KEY(b)) PARTITION BY KEY(b) PARTITIONS 6;
Query OK, 0 rows affected (0.02 sec)
mysql> ALTER TABLE t1 RENAME TO t2, ALGORITHM = INSTANT;
Query OK, 0 rows affected (0.01 sec)
mysql> ALTER TABLE t2 ALTER COLUMN b SET DEFAULT 100, ALGORITHM = INSTANT;
Query OK, 0 rows affected (0.00 sec)
mysql> ALTER TABLE t2 ALTER COLUMN b DROP DEFAULT, ALGORITHM = INSTANT;
Query OK, 0 rows affected (0.01 sec)
mysql> ALTER TABLE t2 ADD COLUMN c ENUM('a', 'b', 'c'), ALGORITHM = INSTANT;
Query OK, 0 rows affected (0.01 sec)
mysql> ALTER TABLE t2 MODIFY COLUMN c ENUM('a', 'b', 'c', 'd', 'e'), ALGORITHM = INSTANT;
Query OK, 0 rows affected (0.01 sec)
mysql> ALTER TABLE t2 ADD COLUMN (d INT GENERATED ALWAYS AS (a + 1) VIRTUAL), ALGORITHM = INSTANT;
Query OK, 0 rows affected (0.02 sec)
mysql> ALTER TABLE t2 ALTER COLUMN a SET DEFAULT 20,
-> ALTER COLUMN b SET DEFAULT 200, ALGORITHM = INSTANT;
Query OK, 0 rows affected (0.01 sec)
mysql> CREATE TABLE t3 (a INT, b INT) PARTITION BY LIST(a)(
-> PARTITION mypart1 VALUES IN (1,3,5),
-> PARTITION MyPart2 VALUES IN (2,4,6)
-> );
Query OK, 0 rows affected (0.03 sec)
mysql> ALTER TABLE t3 ALTER COLUMN a SET DEFAULT 20, ALTER COLUMN b SET DEFAULT 200, ALGORITHM = INSTANT;
Query OK, 0 rows affected (0.01 sec)
mysql> CREATE TABLE t4 (a INT, b INT) PARTITION BY RANGE(a)
-> (PARTITION p0 VALUES LESS THAN(100), PARTITION p1 VALUES LESS THAN(1000),
-> PARTITION p2 VALUES LESS THAN MAXVALUE);
Query OK, 0 rows affected (0.05 sec)
mysql> ALTER TABLE t4 ALTER COLUMN a SET DEFAULT 20,
-> ALTER COLUMN b SET DEFAULT 200, ALGORITHM = INSTANT;
Query OK, 0 rows affected (0.01 sec)
/* Sub-partitioning example */
mysql> CREATE TABLE ts (id INT, purchased DATE, a INT, b INT)
-> PARTITION BY RANGE( YEAR(purchased) )
-> SUBPARTITION BY HASH( TO_DAYS(purchased) )
-> SUBPARTITIONS 2 (
-> PARTITION p0 VALUES LESS THAN (1990),
-> PARTITION p1 VALUES LESS THAN (2000),
-> PARTITION p2 VALUES LESS THAN MAXVALUE
-> );
Query OK, 0 rows affected (0.10 sec)
mysql> ALTER TABLE ts ALTER COLUMN a SET DEFAULT 20,
-> ALTER COLUMN b SET DEFAULT 200, ALGORITHM = INSTANT;
Query OK, 0 rows affected (0.01 sec)
```
## Fast DDL (Aurora MySQL Version 2)
Schnelle DDL in Aurora MySQL ist eine Optimierung, mit der die Leistung bestimmter Schemaänderungen, wie das Hinzufügen oder Löschen von Spalten, verbessert werden soll, indem die Ausfallzeit und der Ressourcenverbrauch reduziert werden. Dadurch können diese Operationen im Vergleich zu herkömmlichen DDL-Methoden effizienter ausgeführt werden.
**Wichtig**
Zurzeit müssen Sie den Aurora-Labormodus aktivieren, um schnelle DDL verwenden zu können. Weitere Informationen zum Aktivieren des Labormodus finden Sie unter [Amazon Aurora MySQL-Labor-Modus](AuroraMySQL.Updates.LabMode.md).
Die Optimierung für schnelle DDL wurde ursprünglich im Labormodus für Aurora-MySQL-Version 2 eingeführt, um die Effizienz bestimmter DDL-Operationen zu verbessern. In Aurora-MySQL-Version 3 wurde der Labormodus eingestellt und schnelle DDL wurde durch die MySQL-8.0-Funktion für sofortige DDL ersetzt.
In MySQL wirken sich viele Data Definition Language (DDL)-Vorgänge signifikant auf die Leistungsfähigkeit aus.
Nehmen wir beispielsweise an, dass Sie eine `ALTER TABLE`-Operation verwenden, um eine Spalte zu einer Tabelle hinzuzufügen. Abhängig vom angegebenen Algorithmus für den Vorgang kann der Vorgang Folgendes beinhalten:
+ Erstellen einer vollen Kopie für die Tabelle
+ Erstellen einer temporären Tabelle für die Verarbeitung simultaner Data Manipulation Language (DML)-Vorgänge
+ Erneutes Aufbauen aller Indizes für die Tabelle
+ Anwenden von Tabellensperren beim Vornehmen von simultanen DML-Änderungen
+ Verlangsamen des simultanen DML-Durchsatzes
Diese Leistungsbeeinträchtigung kann in Umgebungen mit großen Tabellen oder hohem Transaktionsvolumen eine besondere Herausforderung darstellen. Schnelle DDL trägt dazu bei, diese Herausforderungen zu minimieren, indem Schemaänderungen optimiert werden, was schnellere und weniger ressourcenintensive Operationen ermöglicht.
### Schnelle DDL-Beschränkungen
Aktuell hat Fast DDL folgende Einschränkungen:
+ Sie unterstützt nur das Hinzufügen von löschbaren Spalten, ohne Standardwerte, bis zum Ende einer bestehenden Tabelle.
+ Schnelle DDL funktioniert nicht für partitionierte Tabellen.
+ Schnelle DDL funktioniert nicht für InnoDB-Tabellen, die das Zeilenformat REDUNDANT verwenden.
+ Schnelle DDL funktioniert nicht für Tabellen mit Volltextsuchindizes.
+ Wenn die maximal mögliche Datensatzgröße für die DDL-Operation zu groß ist, wird Fast DDL nicht verwendet. Eine Datensatzgröße ist zu groß, wenn sie größer als die Hälfte der Seitengröße ist. Die maximale Größe eines Datensatzes wird berechnet, indem die maximale Größe aller Spalten addiert wird. Bei Spalten variabler Größe werden nach InnoDB-Standards externe Bytes für die Berechnung nicht berücksichtigt.
### Schnelle DDL-Syntax
```
ALTER TABLE tbl_name ADD COLUMN col_name column_definition
```
Dieses Statement verwendet die folgenden Optionen:
+ **`tbl_name` — **Der Name der Tabelle, die geändert werden soll.
+ **`col_name` — **Der Name der Spalte, die hinzugefügt werden soll.
+ **`col_definition` — **Die Definition der Spalte, die hinzugefügt werden soll.
**Anmerkung**
Sie müssen eine löschbare Spaltendefinition ohne einen Standardwert festlegen. Andernfalls kann Fast DDL nicht verwendet werden.
### Fast DDL-Beispiele
Die folgenden Beispiele veranschaulichen die Beschleunigung von Fast-DDL-Operationen. Im ersten SQL-Beispiel werden `ALTER TABLE`-Anweisungen für eine große Tabelle ausgeführt, ohne Fast DDL zu verwenden. Diese Operation benötigt beträchtliche Zeit. Ein CLI-Beispiel zeigt, wie Fast DDL für den Cluster aktiviert wird. Dann führt ein anderes SQL-Beispiel dieselben `ALTER TABLE` Anweisungen für eine identische Tabelle aus. Mit aktiviertem Fast DDL ist der Betrieb sehr schnell.
In diesem Beispiel wird die `ORDERS` Tabelle aus dem TPC-H-Benchmark verwendet, die 150 Millionen Zeilen enthält. Dieser Cluster verwendet absichtlich eine relativ kleine Instance-Klasse, um zu demonstrieren, wie lange `ALTER TABLE`-Anweisungen dauern können, wenn Sie Fast DDL nicht verwenden können. Im Beispiel wird ein Klon der Originaltabelle erstellt, der identische Daten enthält. Eine Überprüfung der Einstellung für `aurora_lab_mode` bestätigt, dass der Cluster Fast DDL nicht verwenden kann, da der Labormodus nicht aktiviert ist. Dann brauchen `ALTER TABLE ADD COLUMN` Anweisungen beträchtliche Zeit, um am Ende der Tabelle neue Spalten hinzuzufügen.
```
mysql> create table orders_regular_ddl like orders;
Query OK, 0 rows affected (0.06 sec)
mysql> insert into orders_regular_ddl select * from orders;
Query OK, 150000000 rows affected (1 hour 1 min 25.46 sec)
mysql> select @@aurora_lab_mode;
+-------------------+
| @@aurora_lab_mode |
+-------------------+
| 0 |
+-------------------+
mysql> ALTER TABLE orders_regular_ddl ADD COLUMN o_refunded boolean;
Query OK, 0 rows affected (40 min 31.41 sec)
mysql> ALTER TABLE orders_regular_ddl ADD COLUMN o_coverletter varchar(512);
Query OK, 0 rows affected (40 min 44.45 sec)
```
In diesem Beispiel wird die gleiche Vorbereitung einer großen Tabelle wie im vorherigen Beispiel durchgeführt. Sie können den Labor-Modus jedoch nicht einfach innerhalb einer interaktiven SQL-Sitzung aktivieren. Diese Einstellung muss in einer benutzerdefinierten Parametergruppe aktiviert sein. Dazu müssen Sie die `mysql` Sitzung verlassen und einige AWS CLI-Befehle ausführen oder die AWS-Managementkonsole verwenden.
```
mysql> create table orders_fast_ddl like orders;
Query OK, 0 rows affected (0.02 sec)
mysql> insert into orders_fast_ddl select * from orders;
Query OK, 150000000 rows affected (58 min 3.25 sec)
mysql> set aurora_lab_mode=1;
ERROR 1238 (HY000): Variable 'aurora_lab_mode' is a read only variable
```
Das Aktivieren des Labor-Modus für den Cluster erfordert einige Arbeiten an einer Parametergruppe. In diesem Beispiel für eine AWS CLI wird eine Clusterparametergruppe verwendet, um sicherzustellen, dass alle DB-Instances im Cluster den gleichen Wert für die Einstellung des Labor-Modus verwenden.
```
$ aws rds create-db-cluster-parameter-group \
--db-parameter-group-family aurora5.7 \
--db-cluster-parameter-group-name lab-mode-enabled-57 --description 'TBD'
$ aws rds describe-db-cluster-parameters \
--db-cluster-parameter-group-name lab-mode-enabled-57 \
--query '*[*].[ParameterName,ParameterValue]' \
--output text | grep aurora_lab_mode
aurora_lab_mode 0
$ aws rds modify-db-cluster-parameter-group \
--db-cluster-parameter-group-name lab-mode-enabled-57 \
--parameters ParameterName=aurora_lab_mode,ParameterValue=1,ApplyMethod=pending-reboot
{
"DBClusterParameterGroupName": "lab-mode-enabled-57"
}
# Assign the custom parameter group to the cluster that's going to use Fast DDL.
$ aws rds modify-db-cluster --db-cluster-identifier tpch100g \
--db-cluster-parameter-group-name lab-mode-enabled-57
{
"DBClusterIdentifier": "tpch100g",
"DBClusterParameterGroup": "lab-mode-enabled-57",
"Engine": "aurora-mysql",
"EngineVersion": "5.7.mysql_aurora.2.10.2",
"Status": "available"
}
# Reboot the primary instance for the cluster tpch100g:
$ aws rds reboot-db-instance --db-instance-identifier instance-2020-12-22-5208
{
"DBInstanceIdentifier": "instance-2020-12-22-5208",
"DBInstanceStatus": "rebooting"
}
$ aws rds describe-db-clusters --db-cluster-identifier tpch100g \
--query '*[].[DBClusterParameterGroup]' --output text
lab-mode-enabled-57
$ aws rds describe-db-cluster-parameters \
--db-cluster-parameter-group-name lab-mode-enabled-57 \
--query '*[*].{ParameterName:ParameterName,ParameterValue:ParameterValue}' \
--output text | grep aurora_lab_mode
aurora_lab_mode 1
```
Das folgende Beispiel zeigt die verbleibenden Schritte, nachdem die Änderung der Parametergruppe wirksam wird. Es testet die Einstellung für `aurora_lab_mode`, um sicherzustellen, dass der Cluster Fast DDL verwenden kann. Dann führt es `ALTER TABLE` Anweisungen aus, um Spalten am Ende einer anderen großen Tabelle hinzuzufügen. Dieses Mal werden die Anweisungen sehr schnell beendet.
```
mysql> select @@aurora_lab_mode;
+-------------------+
| @@aurora_lab_mode |
+-------------------+
| 1 |
+-------------------+
mysql> ALTER TABLE orders_fast_ddl ADD COLUMN o_refunded boolean;
Query OK, 0 rows affected (1.51 sec)
mysql> ALTER TABLE orders_fast_ddl ADD COLUMN o_coverletter varchar(512);
Query OK, 0 rows affected (0.40 sec)
```
# Anzeigen des Volume-Status für einen Aurora MySQL-DB-Cluster
In Amazon Aurora besteht ein DB-Cluster-Volume aus einer Sammlung von logischen Blöcken. Jeder von ihnen stellt 10 Gigabyte des zugeteilten Arbeitsspeichers bereit. Diese Blöcke werden als *Schutzgruppen* bezeichnet.
Die Daten in den einzelnen Schutzgruppen werden über sechs physische Speichereinheiten, so genannte *Speicherknoten*, repliziert. Diese Speicherknoten werden in drei Availability Zones (AZs) in der AWS-Region zugeteilt, in der sich das DB-Cluster befindet. Jeder Speicherknoten wiederum besteht aus einem oder mehreren logischen Datenblöcken für das DB-Cluster-Volume. Weitere Informationen zu Schutzgruppen und Speicherknoten finden Sie unter [Introducing the Aurora Storage Engine](https://aws.amazon.com/blogs/database/introducing-the-aurora-storage-engine/) im AWS Database Blog.
Sie können den Ausfall eines gesamten Speicherknotens oder den eines einzelnen Datenblocks innerhalb eines Speicherknotens simulieren. Verwenden Sie hierfür die Fehlersimulationsanweisung `ALTER SYSTEM SIMULATE DISK FAILURE`. Sie geben für die Anweisung den Indexwert eines spezifischen logischen Datenblocks oder Speicherknotens an. Wenn Sie jedoch einen Indexwert angeben, der größer als die Anzahl der vom DB-Cluster-Volume verwendeten logischen Datenblöcke oder Speicherknoten ist, gibt die Anweisung einen Fehler zurück. Weitere Informationen über Fehlersimulationsabfragen finden Sie unter [Testen von Amazon Aurora MySQL unter Verwendung von Fehlersimulationsabfragen](AuroraMySQL.Managing.FaultInjectionQueries.md).
Sie können diesen Fehler vermeiden, indem Sie die Anweisung `SHOW VOLUME STATUS` verwenden. Die Anweisung gibt zwei Serverstatusvariablen zurück, `Disks` und `Nodes`. Diese Variablen stellen jeweils die gesamte Anzahl an logischen Datenblocks und Speicherknoten für das DB-Cluster-Volume dar.
## Syntax
```
SHOW VOLUME STATUS
```
## Beispiel
Das folgende Beispiel zeigt ein typisches Ergebnis von SHOW VOLUME STATUS.
```
mysql> SHOW VOLUME STATUS;
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| Disks | 96 |
| Nodes | 74 |
+---------------+-------+
```