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. # io/aurora\$1redo\$1log\$1flush Dieses `io/aurora_redo_log_flush`-Ereignis tritt ein, wenn eine Sitzung persistente Daten in den Amazon-Aurora-Speicher schreibt. **Topics** + [Unterstützte Engine-Versionen](#ams-waits.io-auredologflush.context.supported) + [Kontext](#ams-waits.io-auredologflush.context) + [Wahrscheinliche Ursachen für erhöhte Wartezeiten](#ams-waits.io-auredologflush.causes) + [Aktionen](#ams-waits.io-auredologflush.actions) ## Unterstützte Engine-Versionen Diese Warteereignisinformationen werden für die folgenden Engine-Versionen unterstützt: + Aurora-MySQL-Version 2 ## Kontext Das `io/aurora_redo_log_flush` Ereignis bezieht sich auf einen Schreibvorgang input/output (I/O) in Aurora MySQL. **Anmerkung** In Version 3 von Aurora MySQL heißt dieses Warteereignis [io/redo\$1log\$1flush](ams-waits.io-redologflush.md). ## Wahrscheinliche Ursachen für erhöhte Wartezeiten Aus Gründen der Datenpersistenz erfordern Commits ein dauerhaftes Schreiben in einen stabilen Speicher. Wenn die Datenbank zu viele Commits durchführt, gibt es bei der I/O Schreiboperation ein Wartungsereignis, das `io/aurora_redo_log_flush` Wait-Ereignis. In den folgenden Beispielen werden 50 000 Datensätze mithilfe der db.r5.xlarge DB-Instance-Klasse in einen Aurora-MySQL-DB-Cluster eingefügt: + Im ersten Beispiel fügt jede Sitzung zeilenweise 10 000 Datensätze ein. Wenn sich ein DML-Befehl (Data Manipulation Language) nicht innerhalb einer Transaktion befindet, verwendet Aurora MySQL standardmäßig implizite Commits. Autocommit ist aktiviert. Dies bedeutet, dass für jede Zeileneinfügung ein Commit vorhanden ist. Performance Insights zeigt, dass die Verbindungen die meiste Zeit damit verbringen, auf das `io/aurora_redo_log_flush`-Warteereignis zu warten. ![\[Beispiel für Performance Insights für das Warteereignis\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/images/auredologflush_PI_example1.png) Dies wird durch die verwendeten einfachen Einfügungsanweisungen verursacht. ![\[Einfügungsanweisungen in Top-SQL\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/images/auredologflush_top_SQL1.png) Die 50 000 Datensätze benötigen 3,5 Minuten, um eingefügt zu werden. + Im zweiten Beispiel werden Einfügungen in 1 000 Batches vorgenommen, d.h. jede Verbindung führt 10 Commits statt 10 000 aus. Performance Insights zeigt, dass die Verbindungen nicht die meiste Zeit mit dem `io/aurora_redo_log_flush`-Warteereignis verbringen. ![\[Performance-Insights-Beispiel für das Warteereignis, das weniger Auswirkungen hat\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/images/auredologflush_PI_example2.png) Die 50 000 Datensätze benötigen 4 Sekunden, um eingefügt zu werden. ## Aktionen Abhängig von den Ursachen Ihres Warteereignisses empfehlen wir verschiedene Aktionen. **Topics** + [Identifizieren Sie die problematischen Sitzungen und Abfragen](#ams-waits.io-auredologflush.actions.identify-queries) + [Gruppieren Sie Ihre Schreiboperationen](#ams-waits.io-auredologflush.actions.action0) + [Deaktivieren Sie Autocommit](#ams-waits.io-auredologflush.actions.action1) + [Transaktionen verwenden](#ams-waits.io-auredologflush.action2) + [Verwenden von Batches](#ams-waits.io-auredologflush.action3) ### Identifizieren Sie die problematischen Sitzungen und Abfragen Wenn Ihre DB-Instance einen Engpass hat, besteht Ihre erste Aufgabe darin, die Sitzungen und Abfragen zu finden, die ihn verursachen. Einen nützlichen AWS Datenbank-Blogbeitrag finden Sie unter [Analysieren von Amazon Aurora MySQL-Workloads mit Performance Insights](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/). **So identifizieren Sie Sitzungen und Abfragen, die einen Engpass verursachen** 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 **Performance-Insights** aus. 1. Wählen Sie Ihre DB-Instance aus. 1. Wählen Sie unter **Datenbanklast** die Option **Nach Wartezeit aufteilen**. 1. Wählen Sie unten auf der Seite **Top-SQL** aus. Die Abfragen oben in der Liste verursachen die höchste Belastung der Datenbank. ### Gruppieren Sie Ihre Schreiboperationen Die folgenden Beispiele lösen das `io/aurora_redo_log_flush`-Warteereignis aus. (Autocommit ist aktiviert.) ``` INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx'); INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx'); INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx'); .... INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx'); UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE id=xx; UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE id=xx; UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE id=xx; .... UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE id=xx; DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx; DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx; DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx; .... DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx; ``` Um die Wartezeit auf das `io/aurora_redo_log_flush`-Wartezeitereignis zu verkürzen, gruppieren Sie Ihre Schreibvorgänge logisch in einem einzigen Commit, um persistente Speicheraufrufe zu reduzieren. ### Deaktivieren Sie Autocommit Deaktivieren Sie Autocommit, bevor Sie große Änderungen vornehmen, die nicht in einer Transaktion enthalten sind, wie im folgenden Beispiel gezeigt. ``` SET SESSION AUTOCOMMIT=OFF; UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE sampleCol1=xx; UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE sampleCol1=xx; UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE sampleCol1=xx; .... UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE sampleCol1=xx; -- Other DML statements here COMMIT; SET SESSION AUTOCOMMIT=ON; ``` ### Transaktionen verwenden Sie können Transaktionen verwenden, wie im folgenden Beispiel gezeigt. ``` BEGIN INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx'); INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx'); INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx'); .... INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx'); DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx; DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx; DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx; .... DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx; -- Other DML statements here END ``` ### Verwenden von Batches Sie können Änderungen in Batches vornehmen, wie im folgenden Beispiel gezeigt. Die Verwendung zu großer Batches kann jedoch zu Leistungsproblemen führen, insbesondere bei Read Replicas oder bei der point-in-time Wiederherstellung (PITR). ``` INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx'),('xxxx','xxxxx'),...,('xxxx','xxxxx'),('xxxx','xxxxx'); UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE sampleCol1 BETWEEN xx AND xxx; DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1