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

O evento `io/redo_log_flush` ocorre quando uma sessão está gravando dados persistentes no armazenamento do Amazon Aurora.

**Topics**
+ [Versões compatíveis do mecanismo](#ams-waits.io-redologflush.context.supported)
+ [Contexto](#ams-waits.io-redologflush.context)
+ [Possíveis causas do maior número de esperas](#ams-waits.io-redologflush.causes)
+ [Ações](#ams-waits.io-redologflush.actions)

## Versões compatíveis do mecanismo
<a name="ams-waits.io-redologflush.context.supported"></a>

Essas informações de eventos de espera têm suporte nas seguintes versões do mecanismo:
+ Aurora MySQL versão 3

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

O evento `io/redo_log_flush` refere-se a uma operação de entrada/saída (E/S) no Aurora MySQL.

**nota**  
No Aurora MySQL versão 2, esse evento de espera é denominado [io/aurora\$1redo\$1log\$1flush](ams-waits.io-auredologflush.md).

## Possíveis causas do maior número de esperas
<a name="ams-waits.io-redologflush.causes"></a>

Para persistência de dados, as confirmações exigem uma gravação durável no armazenamento estável. Se o banco de dados estiver fazendo muitas confirmações, significa que há um evento de espera na operação de E/S de gravação, o evento de espera `io/redo_log_flush`.

Para ver exemplos do comportamento desse evento de espera, consulte [io/aurora\$1redo\$1log\$1flush](ams-waits.io-auredologflush.md).

## Ações
<a name="ams-waits.io-redologflush.actions"></a>

Recomenda-se ações distintas, dependendo dos motivos do evento de espera.

**Topics**
+ [Identificar as sessões e consultas problemáticas](#ams-waits.io-redologflush.actions.identify-queries)
+ [Agrupar suas operações de gravação](#ams-waits.io-redologflush.actions.action0)
+ [Desativar a confirmação automática](#ams-waits.io-redologflush.actions.action1)
+ [Utilizar transações](#ams-waits.io-redologflush.action2)
+ [Utilizar lotes](#ams-waits.io-redologflush.action3)

### Identificar as sessões e consultas problemáticas
<a name="ams-waits.io-redologflush.actions.identify-queries"></a>

Se a sua instância de banco de dados estiver enfrentando um gargalo, a primeira tarefa é encontrar as sessões e consultas responsáveis. Leia esta útil postagem no blog de banco dados da AWS sobre como [Analisar workloads do Amazon Aurora MySQL com o Performance Insights](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/).

**Para identificar sessões e consultas que estão causam um gargalo**

1. Faça login no Console de gerenciamento da AWS e abra o console do Amazon RDS em [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).

1. No painel de navegação, escolha **Performance Insights**.

1. Escolha a instância de banco de dados.

1. Em **Database load** (Carga de banco de dados), escolha **Slice by wait** (Segmentar por espera).

1. Na parte inferior da página, escolha **Top SQL** (SQL principal).

   As consultas na parte superior da lista estão causando a maior carga no banco de dados.

### Agrupar suas operações de gravação
<a name="ams-waits.io-redologflush.actions.action0"></a>

Os exemplos a seguir acionam o evento de espera `io/redo_log_flush`. (A confirmação automática está habilitada.)

```
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 reduzir o tempo gasto esperando no evento de espera `io/redo_log_flush`, agrupe suas operações de gravação logicamente em uma única confirmação para reduzir chamadas persistentes ao armazenamento.

### Desativar a confirmação automática
<a name="ams-waits.io-redologflush.actions.action1"></a>

Desative a confirmação automática antes de fazer grandes alterações que não estejam em uma transação, conforme mostrado no exemplo a seguir.

```
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 transações
<a name="ams-waits.io-redologflush.action2"></a>

É possível utilizar transações, conforme mostrado no exemplo a seguir.

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

Você pode fazer alterações em lotes, conforme mostrado no exemplo a seguir. No entanto, o uso de lotes muito grandes pode causar problemas de performance, especialmente em réplicas de leitura ou ao fazer uma recuperação em um ponto anterior no tempo (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;
```