io/aurora_redo_log_flush

L’evento io/aurora_redo_log_flush si verifica quando una sessione sta scrivendo dati persistenti nell’archiviazione di Amazon Aurora.

Versioni del motore supportate

Queste informazioni sull'evento di attesa sono supportate per le seguenti versioni del motore:

• Aurora MySQL versione 2

Context

L’evento io/aurora_redo_log_flush è per un'operazione di input/output di scrittura (I/O) in Aurora MySQL.

Nota

Nella versione 3 di Aurora MySQL, questo evento di attesa è denominato io/redo_log_flush.

Probabili cause di aumento delle attese

Per la persistenza dei dati, l’esecuzione dei commit richiede una scrittura duratura per un’archiviazione stabile. Se il database sta eseguendo troppi commit, c'è un evento di attesa sull'operazione di I/O di scrittura, l’evento di attesa io/aurora_redo_log_flush.

Negli esempi seguenti, 50.000 dati vengono inseriti in un cluster di database di Aurora MySQL utilizzando la classe di istanza database db.r5.xlarge:

• Nel primo esempio, ogni sessione inserisce 10.000 dati riga per riga. Per impostazione predefinita, se un comando del linguaggio di manipolazione dei dati (DML) non si trova all'interno di una transazione, Aurora MySQL utilizza l’esecuzione di commit impliciti. Autocommit è attivo. Ciò significa che per ogni inserimento di riga è presente l’esecuzione di un commit. Performance Insights mostra che le connessioni dedicano la maggior parte del tempo in attesa dell’evento di attesa io/aurora_redo_log_flush.

  

  Ciò è causato dalle semplici istruzioni di inserimento utilizzate.

  

  I 50.000 dati richiedono 3,5 minuti per essere inseriti.

• Nel secondo esempio, gli inserti sono realizzati in 1.000 batch, ovvero ogni connessione esegue 10 commit anziché 10.000. Performance Insights mostra che le connessioni non dedicano la maggior parte del loro tempo sull’evento di attesa io/aurora_redo_log_flush.

  

  I 50.000 dati richiedono 4 secondi per essere inseriti.

Azioni

Consigliamo azioni diverse a seconda delle cause dell'evento di attesa.

Identificare le sessioni e le query problematiche

Se l'istanza database sta riscontrando un collo di bottiglia, il primo compito è quello di trovare le sessioni e le query che lo causano. Per un utile Post del blog sul database AWS, consulta Analizza i carichi di lavoro di Amazon Aurora MySQL con Performance Insights.

Per identificare sessioni e query che causano un collo di bottiglia

1. Accedi alla AWS Management Console e apri la console Amazon RDS all'indirizzo https://console.aws.amazon.com/rds/.

2. Nel pannello di navigazione scegli Approfondimenti sulle prestazioni.

3. Scegli l'istanza database.

4. In Carico del database, scegli Dividi per attesa.

5. Nella parte inferiore della pagina scegli Prime Instruzioni SQL.

   Le query nella parte superiore dell'elenco causano il carico più alto sul database.

Raggruppa le operazioni di scrittura

Gli esempi seguenti attivano l’evento di attesa io/aurora_redo_log_flush. (Autocommit è attivo.)

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;

Per ridurre il tempo impiegato in attesa dell’evento di attesa io/aurora_redo_log_flush, raggruppa logicamente le operazioni di scrittura in una singola esecuzione di commit per ridurre le chiamate persistenti all’archiviazione.

Disattivazione dell'autocommit

Disattivare l'autocommit prima di apportare modifiche di grandi dimensioni che non si trovano all'interno di una transazione, come illustrato nell'esempio seguente.

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;

Transazioni di utilizzo

È possibile utilizzare le transazioni, come illustrato nell'esempio seguente.

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

Utilizza i batch

Si può anche apportare modifiche in batch, come nell'esempio seguente: Tuttavia, l'utilizzo di batch troppo grandi può causare problemi di prestazioni, specialmente nelle repliche di lettura o durante il ripristino (PITR). point-in-time

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;