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

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

**Topics**
+ [Versiones del motor admitidas](#ams-waits.io-redologflush.context.supported)
+ [Contexto](#ams-waits.io-redologflush.context)
+ [Causas probables del aumento de las esperas](#ams-waits.io-redologflush.causes)
+ [Acciones](#ams-waits.io-redologflush.actions)

## Versiones del motor admitidas
<a name="ams-waits.io-redologflush.context.supported"></a>

Esta información de evento de espera es compatible con las siguientes versiones del motor:
+ Aurora MySQL versión 3

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

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\$1redo\$1log\$1flush](ams-waits.io-auredologflush.md).

## Causas probables del aumento de las esperas
<a name="ams-waits.io-redologflush.causes"></a>

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\$1redo\$1log\$1flush](ams-waits.io-auredologflush.md).

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

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

**Topics**
+ [Identificar las sesiones y consultas problemáticas](#ams-waits.io-redologflush.actions.identify-queries)
+ [Agrupar sus operaciones de escritura](#ams-waits.io-redologflush.actions.action0)
+ [Desactivar la confirmación automática](#ams-waits.io-redologflush.actions.action1)
+ [Utilizar transacciones](#ams-waits.io-redologflush.action2)
+ [Utilizar lotes](#ams-waits.io-redologflush.action3)

### Identificar las sesiones y consultas problemáticas
<a name="ams-waits.io-redologflush.actions.identify-queries"></a>

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](https://aws.amazon.com/blogs/database/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 Consola de administración de AWS y abra la consola de Amazon RDS en [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).

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

1. Seleccione la instancia de base de datos.

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

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

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

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

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

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