# io/aurora\_redo\_log\_flush
<a name="ams-waits.io-auredologflush"></a>

O evento `io/aurora_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-auredologflush.context.supported)
+ [Contexto](#ams-waits.io-auredologflush.context)
+ [Possíveis causas do maior número de esperas](#ams-waits.io-auredologflush.causes)
+ [Ações](#ams-waits.io-auredologflush.actions)

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

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

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

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

**nota**  
No Aurora MySQL versão 3, esse evento de espera é denominado [io/redo\_log\_flush](ams-waits.io-redologflush.md).

## Possíveis causas do maior número de esperas
<a name="ams-waits.io-auredologflush.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/aurora_redo_log_flush`.

Nos exemplos a seguir, 50.000 registros são inseridos em um cluster de banco de dados Aurora MySQL com a classe de instância de banco de dados db.r5.xlarge:
+ No primeiro exemplo, cada sessão insere 10.000 registros, linha por linha. Por padrão, se um comando de linguagem de manipulação de dados (DML) não estiver em uma transação, o Aurora MySQL utilizará confirmações implícitas. A confirmação automática está habilitada. Isso significa que há uma confirmação para cada inserção de linha. O Performance Insights mostra que as conexões passam a maior parte do tempo esperando pelo evento de espera `io/aurora_redo_log_flush`.   
![Exemplo no Performance Insights do evento de espera](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/images/auredologflush_PI_example1.png)

  Isso é causado pelas instruções de inserção simples utilizadas.  
![Instruções de inserção em Top SQL (SQL principal)](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/images/auredologflush_top_SQL1.png)

  Os 50.000 registros demoram 3,5 minutos para serem inseridos.
+ No segundo exemplo, as inserções são feitas em 1.000 lotes, ou seja, cada conexão realiza 10 confirmações em vez de 10.000. O Performance Insights mostra que as conexões não passam a maior parte do tempo no evento de espera `io/aurora_redo_log_flush`.  
![Exemplo no Performance Insights do evento de espera com menos impacto](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/images/auredologflush_PI_example2.png)

  Os 50.000 registros demoram 4 segundos para serem inseridos.

## Ações
<a name="ams-waits.io-auredologflush.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-auredologflush.actions.identify-queries)
+ [Agrupar suas operações de gravação](#ams-waits.io-auredologflush.actions.action0)
+ [Desativar a confirmação automática](#ams-waits.io-auredologflush.actions.action1)
+ [Utilizar transações](#ams-waits.io-auredologflush.action2)
+ [Utilizar lotes](#ams-waits.io-auredologflush.action3)

### Identificar as sessões e consultas problemáticas
<a name="ams-waits.io-auredologflush.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-auredologflush.actions.action0"></a>

Os exemplos a seguir acionam o evento de espera `io/aurora_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/aurora_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-auredologflush.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-auredologflush.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-auredologflush.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;
```