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/redo_log_flush
Dieses io/redo_log_flush-Ereignis tritt ein, wenn eine Sitzung persistente Daten in den Amazon-Aurora-Speicher schreibt.
Unterstützte Engine-Versionen
Diese Warteereignisinformationen werden für die folgenden Engine-Versionen unterstützt:
-
Aurora-MySQL-Version 3
Kontext
Das io/redo_log_flush-Ereignis ist für eine Schreiboperation mit Ein-/Ausgabe (I/O) in Aurora MySQL vorgesehen.
Anmerkung
In Aurora MySQL Version 2 heißt dieses Warteereignis io/aurora_redo_log_flush.
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 ausführt, gibt es ein Warteereignis für die I/O-Schreiboperation, das io/redo_log_flush-Warteereignis.
Beispiele für das Verhalten dieses Warteereignisses finden Sie unter io/aurora_redo_log_flush.
Aktionen
Abhängig von den Ursachen Ihres Warteereignisses empfehlen wir verschiedene Aktionen.
Themen
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
So identifizieren Sie Sitzungen und Abfragen, die einen Engpass verursachen
Melden Sie sich bei der AWS-Managementkonsole an und öffnen Sie die Amazon-RDS-Konsole unter https://console.aws.amazon.com/rds/
. -
Wählen Sie im Navigationsbereich Performance-Insights aus.
-
Wählen Sie Ihre DB-Instance aus.
-
Wählen Sie unter Datenbanklast die Option Nach Wartezeit aufteilen.
-
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/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/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 von zu großen Batches kann jedoch Leistungsprobleme verursachen, insbesondere bei Lesereplikaten oder bei zeitpunktbezogener 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<xx;