io/redo_log_flush - Amazon Aurora
Versiones del motor admitidasContextoCausas probables del aumento del tiempo de esperaAcciones

io/redo_log_flush

El evento io/redo_log_flush se produce cuando una sesión escribe datos persistentes en el almacenamiento de Amazon Aurora.

Versiones del motor admitidas

Esta información de evento de espera es compatible con las siguientes versiones del motor:

  • Aurora MySQL versión 3

Contexto

El evento io/redo_log_flush es para una operación de entrada/salida de escritura (E/S) en Aurora MySQL.

nota

En la versión 2 de Aurora MySQL, este evento de espera se denomina io/aurora_redo_log_flush.

Causas probables del aumento del tiempo de espera

Para la persistencia de datos, las confirmaciones requieren una escritura duradera en un almacenamiento estable. Si la base de datos está realizando demasiadas confirmaciones, se produce un evento de espera en la operación de E/S de escritura, el evento de espera io/redo_log_flush.

Para ver ejemplos del comportamiento de este evento de espera, consulte io/aurora_redo_log_flush.

Acciones

Recomendamos diferentes acciones en función de las causas del evento de espera.

Identificar las sesiones y consultas problemáticas

Si su instancia de base de datos tiene un cuello de botella, la primera tarea que debe realizar es buscar las sesiones y consultas que lo provocan. Para ver una entrada de blog útil sobre AWS Database, consulte Analyze Amazon Aurora MySQL Workloads with Performance Insights.

Para identificar sesiones y consultas que provocan un cuello de botella

  1. Inicie sesión en la AWS Management Console y abra la consola de Amazon RDS en https://console.aws.amazon.com/rds/.

  2. En el panel de navegación, seleccione Información de rendimiento.

  3. Seleccione la instancia de base de datos.

  4. En Database load (Carga de base de datos), elija Slice by wait (Corte por espera).

  5. En la parte inferior de la página, elija Top SQL (SQL principal).

    Las consultas de la parte superior de la lista son las que provocan la mayor carga de la base de datos.

Agrupar sus operaciones de escritura

Los ejemplos siguientes desencadenan el evento de espera io/redo_log_flush. (La opción Autocommit [Confirmar automáticamente] está activada).

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;

Para reducir el tiempo de espera en el evento de espera io/redo_log_flush, agrupe sus operaciones de escritura de forma lógica en una única confirmación para reducir las llamadas persistentes al almacenamiento.

Desactivar la confirmación automática

Desactive la confirmación automática antes de realizar grandes cambios que no están dentro de una transacción, tal como se muestra en el ejemplo siguiente.

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;

Utilizar transacciones

Puede utilizar transacciones, tal como se muestra en el ejemplo siguiente.

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

Utilizar lotes

También puede realizar cambios en lotes, tal como se muestra en el siguiente ejemplo. Sin embargo, el uso de lotes demasiado grandes puede provocar problemas de rendimiento, sobre todo en réplicas de lectura o cuando se realiza una recuperación a un momento dado (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;