Redo log writer is waiting no MySQL: quando o log mostra que o checkpointer não está acompanhando

Em uma coleta de MySQL, o error.log repetia duas mensagens muito específicas:

1
2

[MY-014089] [InnoDB] Redo log writer is waiting for a new redo log file.
Consider increasing innodb_redo_log_capacity.

E:

1
2

[MY-014084] [InnoDB] Threads are unable to reserve space in redo log
which can't be reclaimed due to the 'log_checkpointer' consumer still lagging behind.

A própria mensagem ainda registrava que a capacidade configurada e a capacidade utilizada estavam no mesmo limite.

Na janela coletada, o valor era equivalente a aproximadamente 100 MiB.

Isso é uma evidência forte de pressão no subsistema de redo.

Mas ainda não autoriza uma conclusão simplista como:

“Aumenta innodb_redo_log_capacity e acabou.”

O que o redo log está fazendo #

De forma simplificada, alterações do InnoDB geram registros de redo antes de os dados modificados serem totalmente persistidos nas páginas do tablespace.

Esse mecanismo permite recuperação e evita depender de cada página de dados ser gravada imediatamente.

O fluxo conceitual é:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

transação modifica página
        ↓
redo é produzido
        ↓
redo precisa de espaço reutilizável
        ↓
checkpoint avança
        ↓
páginas sujas são persistidas
        ↓
espaço antigo do redo pode ser reutilizado

Se a produção de redo avança mais rápido do que a capacidade de reciclagem, o espaço disponível começa a desaparecer.

A mensagem mais importante não era só “log cheio” #

O warning mencionava explicitamente:

1

log_checkpointer consumer still lagging behind

Isso muda a qualidade da investigação.

Não é apenas uma variável pequena encontrada no my.cnf.

O próprio InnoDB está dizendo que threads não conseguem reservar novo espaço de redo porque a posição necessária para reaproveitamento ainda não foi liberada pelo progresso do checkpoint.

Em outras palavras:

1
2
3

produção de redo
      >
capacidade de o sistema liberar redo antigo naquele ritmo

O padrão era recorrente, não uma linha isolada #

Na evidência recuperada havia warnings repetidos ao longo de minutos durante uma janela de carga, incluindo várias ocorrências consecutivas de:

1

Redo log writer is waiting for a new redo log file

E ocorrências intercaladas de:

1

Threads are unable to reserve space in redo log...

Outra coleta histórica do mesmo tipo de ambiente também mostrava o warning em datas diferentes.

Isso é mais relevante que encontrar uma linha solta em um log de meses.

A pergunta passa a ser:

isso acontece apenas em picos específicos ou é uma limitação recorrente da configuração/workload?

O primeiro passo é medir a configuração real #

Eu começaria com:

1

SHOW VARIABLES LIKE 'innodb_redo_log_capacity';

Dependendo da versão do MySQL, também vale entender as variáveis legadas relacionadas ao tamanho dos redo logs.

Depois, registrar versão:

1

SELECT VERSION();

Isso importa porque a implementação e as variáveis de redo mudaram entre gerações do MySQL.

Não investigar o redo isolado do storage #

Se o checkpoint está atrasando, eu também quero saber se o sistema consegue escrever no ritmo necessário.

No host:

1
2

iostat -xz 1 10
vmstat 1 10

Procuro sinais como:

1
2
3
4
5

await alto
utilização sustentada do dispositivo
iowait elevado
fila de I/O
pressão geral do filesystem/storage

Porque aumentar espaço de redo pode ampliar a margem para absorver burst, mas não corrige magicamente um storage incapaz de sustentar o workload.

Dirty pages e checkpoint fazem parte da mesma história #

Uma investigação mais completa observa o estado do InnoDB.

Por exemplo:

1

SHOW ENGINE INNODB STATUS\G

E métricas relacionadas a buffer pool, dirty pages e flush.

A pergunta não é encontrar uma única variável culpada.

É reconstruir:

1
2
3
4
5

quanto redo está sendo produzido?
quão rápido checkpoint avança?
quanto dado precisa ser flushado?
o storage acompanha?
a configuração dá margem para o burst observado?

Aumentar a capacidade pode ser correto #

O próprio warning recomenda considerar o aumento de innodb_redo_log_capacity.

Isso não deve ser ignorado.

Se o valor configurado é pequeno para o volume real de escrita, aumentar a capacidade pode reduzir a frequência em que o workload encontra o limite e dar mais espaço para o checkpoint acompanhar picos.

O ponto é tratar a alteração como hipótese de melhoria sustentada por evidência, e não como RCA universal.

Antes da mudança eu registraria:

1
2
3
4
5
6

valor atual
frequência dos warnings
janela de maior carga
I/O do host
latência percebida
métricas do InnoDB

Depois da mudança, compararia o mesmo conjunto.

O warning não prova sozinho a causa de toda lentidão #

Na mesma janela podem existir:

• queries ruins;
• scans excessivos;
• contenção;
• storage lento;
• checkpoint agressivo;
• buffer pool inadequado;
• picos legítimos de escrita;
• operações de manutenção.

O warning prova uma coisa específica:

houve momentos em que o InnoDB não conseguia reservar novo espaço de redo no ritmo necessário porque a reciclagem/checkpoint estava atrasada.

Isso já é muito útil.

Não precisa transformar essa evidência em uma história maior do que ela é.

Uma coleta reproduzível #

Versão e configuração #

1
2
3

SELECT VERSION();
SHOW VARIABLES LIKE 'innodb_redo_log_capacity';
SHOW VARIABLES LIKE 'innodb_buffer_pool_size';

Estado InnoDB #

1

SHOW ENGINE INNODB STATUS\G

Error log #

1
2

grep -Ei 'MY-014089|MY-014084|redo log|log_checkpointer' \
  /var/log/mysql/error.log | tail -200

Storage #

1
2

iostat -xz 1 10
vmstat 1 10

Workload #

Quando performance_schema/sys estiverem disponíveis, coletar as queries e esperas relevantes sem alterar o ambiente.

Como validar uma mudança #

Se for decidido aumentar a capacidade de redo, eu definiria antes o critério de sucesso.

Exemplo:

1
2
3
4
5
6

mesma janela de carga
→ warnings deixam de ocorrer ou reduzem fortemente
→ latência não piora
→ storage não entra em saturação
→ checkpoint mantém progresso
→ nenhuma regressão operacional

Sem medição posterior, a alteração vira apenas configuração nova.

O que a fonte deste artigo comprova #

A coleta técnica recuperada comprova:

• warnings MY-014089 repetidos;
• warnings MY-014084 repetidos;
• mensagens dizendo que o redo writer aguardava novo arquivo;
• threads sem conseguir reservar espaço de redo;
• log_checkpointer descrito pelo próprio MySQL como atrasado;
• capacidade de redo totalmente utilizada na janela registrada;
• recomendação do próprio InnoDB para considerar aumento da capacidade.

Ela não comprova, por si só:

• que aumentar a capacidade foi a correção final;
• que o storage era a causa raiz;
• que toda lentidão da aplicação vinha do redo;
• um percentual de melhoria depois da alteração.

Checklist #

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

[ ] confirmar versão do MySQL
[ ] confirmar innodb_redo_log_capacity
[ ] contar frequência dos warnings
[ ] delimitar janela de ocorrência
[ ] coletar SHOW ENGINE INNODB STATUS
[ ] observar dirty pages/checkpoint
[ ] coletar iostat/vmstat
[ ] correlacionar com workload
[ ] definir hipótese de ajuste
[ ] definir critério de validação antes da mudança
[ ] medir novamente na mesma classe de carga

O principal aprendizado #

Quando o InnoDB escreve:

1

Redo log writer is waiting

isso não é ruído cosmético.

É uma evidência concreta de que o pipeline de redo/checkpoint encontrou seu limite naquele momento.

A melhor resposta não é ignorar o warning — nem obedecer cegamente à sugestão de configuração.

É usar a mensagem como ponto de partida para medir redo, checkpoint, dirty pages, storage e workload como uma cadeia.