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/redo\$1log\$1flush
<a name="ams-waits.io-redologflush"></a>

L’evento `io/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-redologflush.context.supported)
+ [Contesto](#ams-waits.io-redologflush.context)
+ [Probabili cause di aumento delle attese](#ams-waits.io-redologflush.causes)
+ [Azioni](#ams-waits.io-redologflush.actions)

## Versioni del motore supportate
<a name="ams-waits.io-redologflush.context.supported"></a>

Queste informazioni sull'evento di attesa sono supportate per le seguenti versioni del motore:
+ Aurora MySQL versione 3

## Contesto
<a name="ams-waits.io-redologflush.context"></a>

L'`io/redo_log_flush`evento riguarda un'operazione di scrittura input/output (I/O) in Aurora MySQL.

**Nota**  
In Aurora MySQL versione 2, questo evento di attesa è denominato [io/aurora\$1redo\$1log\$1flush](ams-waits.io-auredologflush.md).

## Probabili cause di aumento delle attese
<a name="ams-waits.io-redologflush.causes"></a>

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/redo_log_flush`

Per esempi del comportamento di questo evento di attesa, consulta [io/aurora\$1redo\$1log\$1flush](ams-waits.io-auredologflush.md).

## Azioni
<a name="ams-waits.io-redologflush.actions"></a>

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

**Topics**
+ [Identificare le sessioni e le query problematiche](#ams-waits.io-redologflush.actions.identify-queries)
+ [Raggruppa le operazioni di scrittura](#ams-waits.io-redologflush.actions.action0)
+ [Disattivazione dell'autocommit](#ams-waits.io-redologflush.actions.action1)
+ [Transazioni di utilizzo](#ams-waits.io-redologflush.action2)
+ [Utilizza i batch](#ams-waits.io-redologflush.action3)

### Identificare le sessioni e le query problematiche
<a name="ams-waits.io-redologflush.actions.identify-queries"></a>

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
<a name="ams-waits.io-redologflush.actions.action0"></a>

Gli esempi seguenti attivano l’evento di attesa `io/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/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
<a name="ams-waits.io-redologflush.actions.action1"></a>

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
<a name="ams-waits.io-redologflush.action2"></a>

È 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
<a name="ams-waits.io-redologflush.action3"></a>

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<xx;
```