Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà. # io/aurora\$1redo\$1log\$1flush L’evento `io/aurora_redo_log_flush` si verifica quando una sessione sta scrivendo dati persistenti nell’archiviazione di Amazon Aurora. **Topics** + [Versioni del motore supportate](#ams-waits.io-auredologflush.context.supported) + [Contesto](#ams-waits.io-auredologflush.context) + [Probabili cause di aumento delle attese](#ams-waits.io-auredologflush.causes) + [Azioni](#ams-waits.io-auredologflush.actions) ## Versioni del motore supportate Queste informazioni sull'evento di attesa sono supportate per le seguenti versioni del motore: + Aurora MySQL versione 2 ## Contesto L'`io/aurora_redo_log_flush`evento riguarda un'operazione di scrittura input/output (I/O) in Aurora MySQL. **Nota** Nella versione 3 di Aurora MySQL, questo evento di attesa è denominato [io/redo\$1log\$1flush.](ams-waits.io-redologflush.md) ## 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 esegue troppi commit, c'è un evento di attesa nell' I/O operazione di scrittura, l'evento wait. `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`. ![\[Esempio di Performance Insights dell’evento di attesa\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/auredologflush_PI_example1.png) Ciò è causato dalle semplici istruzioni di inserimento utilizzate. ![\[Inserisci istruzioni in Istruzioni SQL principali\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/auredologflush_top_SQL1.png) 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`. ![\[Esempio di Performance Insights dell’evento di attesa con minore impatto\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/auredologflush_PI_example2.png) I 50.000 dati richiedono 4 secondi per essere inseriti. ## Azioni Consigliamo azioni diverse a seconda delle cause dell’evento di attesa. **Topics** + [Identificare le sessioni e le query problematiche](#ams-waits.io-auredologflush.actions.identify-queries) + [Raggruppa le operazioni di scrittura](#ams-waits.io-auredologflush.actions.action0) + [Disattivazione dell'autocommit](#ams-waits.io-auredologflush.actions.action1) + [Transazioni di utilizzo](#ams-waits.io-auredologflush.action2) + [Utilizza i batch](#ams-waits.io-auredologflush.action3) ### 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 sul blog AWS Database, consulta [Analizza i carichi di lavoro MySQL di Amazon Aurora](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/) con Performance Insights. **Per identificare sessioni e query che causano un collo di bottiglia** 1. Accedi a Console di gestione AWS e apri la console Amazon RDS all'indirizzo [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/). 1. Nel pannello di navigazione scegli **Approfondimenti sulle prestazioni**. 1. Scegli l'istanza database. 1. In **Carico del database**, scegli **Dividi per attesa**. 1. 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 point-in-time ripristino (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