io/redo_log_flush

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

Versions de moteur prises en charge

Ces informations relatives aux événements d'attente sont prises en charge pour les versions de moteur suivantes :

• Aurora MySQL version 3

Contexte

L'événement io/redo_log_flush est destiné à une opération d'entrée/sortie (I/O) dans Aurora MySQL.

Note

Dans Aurora MySQL version 2, cet événement d'attente est nommé io/aurora_redo_log_flush.

Causes probables de l'allongement des temps d'attente

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'opération I/O en écriture, l'événement d'attente io/redo_log_flush.

Pour des exemples du comportement de cet événement d'attente, consultezio/aurora_redo_log_flush.

Actions

Nous recommandons différentes actions selon les causes de l'événement d'attente.

Identifier les sessions et requêtes problématiques

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 billet de blog AWS Database particulièrement utile, consultez 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 AWS Management Console et ouvrez la console Amazon RDS à l'adresse https://console.aws.amazon.com/rds/.

2. Dans le volet de navigation, choisissez Performance Insights.

3. Sélectionnez votre instance DB.

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

5. 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

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

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

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

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;