Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

# io/redo\$1log\$1flush
<a name="ams-waits.io-redologflush"></a>

L'événement `io/redo_log_flush` se produit lorsqu'une session écrit des données persistantes sur un stockage Amazon Aurora.

**Topics**
+ [Versions de moteur prises en charge](#ams-waits.io-redologflush.context.supported)
+ [Contexte](#ams-waits.io-redologflush.context)
+ [Causes probables de l’augmentation du nombre d’événements d’attente](#ams-waits.io-redologflush.causes)
+ [Actions](#ams-waits.io-redologflush.actions)

## Versions de moteur prises en charge
<a name="ams-waits.io-redologflush.context.supported"></a>

Ces informations relatives aux événements d’attente sont prises en charge pour les versions de moteur suivantes :
+ Aurora MySQL version 3

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

L'`io/redo_log_flush`événement concerne une opération d'écriture input/output (E/S) dans Aurora MySQL.

**Note**  
Dans Aurora MySQL version 2, cet événement d’attente s’appelle [io/aurora\$1redo\$1log\$1flush](ams-waits.io-auredologflush.md).

## Causes probables de l’augmentation du nombre d’événements d’attente
<a name="ams-waits.io-redologflush.causes"></a>

Pour assurer la persistance des données, les validations nécessitent une écriture durable dans un stockage stable. Si la base de données effectue trop de validations, un événement d'attente se produit lors de l' I/O opération d'écriture, l'événement `io/redo_log_flush` d'attente.

Pour des exemples du comportement de cet événement d’attente, consultez [io/aurora\$1redo\$1log\$1flush](ams-waits.io-auredologflush.md).

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

Nous vous recommandons différentes actions en fonction des causes de votre événement d’attente.

**Topics**
+ [Identifier les sessions et requêtes problématiques](#ams-waits.io-redologflush.actions.identify-queries)
+ [Regrouper vos opérations d’écriture](#ams-waits.io-redologflush.actions.action0)
+ [Désactiver la validation automatique](#ams-waits.io-redologflush.actions.action1)
+ [Utiliser des transactions](#ams-waits.io-redologflush.action2)
+ [Utiliser des lots](#ams-waits.io-redologflush.action3)

### Identifier les sessions et requêtes problématiques
<a name="ams-waits.io-redologflush.actions.identify-queries"></a>

Si votre instance de base de données se heure à un goulet d’étranglement, votre première tâche consiste à rechercher les sessions et les requêtes qui en sont à l’origine. Pour un article AWS de blog utile sur les bases de données, consultez [Analyser les charges de travail Amazon Aurora MySQL avec Performance Insights](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/).

**Pour identifier les sessions et les requêtes à l’origine d’un goulet d’étranglement**

1. Connectez-vous à la console Amazon RDS AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)l'adresse.

1. Dans le panneau de navigation, choisissez **Performance Insights**.

1. Sélectionnez votre instance DB.

1. Dans **Database load (Charge de base de données)**, choisissez **Slice by wait (Tranche par attente)**.

1. Au bas de la page, choisissez **Top SQL (Principaux éléments SQL)**.

   Les requêtes situées en haut de la liste imposent la charge la plus élevée sur la base de données.

### Regrouper vos opérations d’écriture
<a name="ams-waits.io-redologflush.actions.action0"></a>

Les exemples suivants déclenchent l’événement d’attente `io/redo_log_flush`. (La validation automatique est activée.)

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

Pour réduire le temps passé à attendre sur l’événement d’attente `io/redo_log_flush`, regroupez logiquement vos opérations d’écriture dans une seule validation et limitez ainsi les appels persistants vers le stockage.

### Désactiver la validation automatique
<a name="ams-waits.io-redologflush.actions.action1"></a>

Désactivez la validation automatique avant d’effectuer d’importantes modifications en dehors d’une transaction, comme le montre l’exemple suivant.

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

### Utiliser des transactions
<a name="ams-waits.io-redologflush.action2"></a>

Vous pouvez utiliser des transactions comme le montre l’exemple suivant.

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

### Utiliser des lots
<a name="ams-waits.io-redologflush.action3"></a>

Vous pouvez apporter des modifications par lots, comme le montre l’exemple suivant. Cependant, l'utilisation de lots trop volumineux peut entraîner des problèmes de performances, en particulier lors de la lecture des répliques ou lors de la point-in-time restauration (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;
```