AWS leva ao MySQL open source otimização de binlog para transações grandes

O gargalo que todo mundo com binlog ligado já sentiu

Quando o MySQL grava uma transação no binlog, os eventos ficam primeiro num buffer em memória controlado por binlog_cache_size (32 KiB por padrão). Se a transação gera mais eventos do que cabem ali, o excesso vai para um arquivo temporário em disco, o spill file. Até esse ponto, tudo roda em paralelo: cada transação tem seu próprio cache ou spill file, sem disputa de lock.

O problema aparece no commit. Para preservar a ordem do binlog, o MySQL serializa as gravações através de um lock global: a transação trava o arquivo de binlog ativo, copia seus eventos do cache (ou do spill file) para dentro dele, e só então libera. Uma transação de 50 GiB, copiando a cerca de 120 MB/s, segura esse lock por aproximadamente 7 minutos, bloqueando qualquer outro commit no servidor inteiro, inclusive de transações que não tocam nos mesmos dados.

Além do bloqueio, há um custo de espaço: enquanto a cópia roda, os mesmos eventos existem duas vezes em disco, no spill file e no binlog principal. E se o servidor reinicia no meio dessa cópia, a recuperação de crash precisa escanear o binlog inteiro para confirmar que a transação terminou e coletar seu ID, atrasando o startup.

O que o BOLT muda no caminho de commit

A AWS descreve a solução (batizada de Binary Log Optimization for Large Transactions, ou BOLT) no AWS Database Blog, publicado em 29 de outubro de 2026. Em vez de copiar os eventos do spill file para o binlog ativo, o BOLT promove o próprio spill file a arquivo de binlog: dá a ele o próximo nome de sequência e o adiciona ao índice, reaproveitando os mesmos passos que o MySQL já usa para rotacionar binlogs.

Com isso, o commit deixa de ser proporcional ao tamanho da transação e passa a ser um trabalho fixo e pequeno. Como os eventos passam a existir em um único lugar (o spill file promovido), o custo de dobro de espaço em disco desaparece junto.

Para marcar o arquivo promovido, o MySQL ganhou um novo evento de binlog, Large_transaction_header_event, que carrega o offset do fim da transação. Na recuperação de crash, em vez de escanear o corpo da transação, o MySQL lê esse evento e pula direto para o próximo registro: segundo a AWS, se o arquivo chegou ao índice, a transação está necessariamente completa, então nem a validação de checksum precisa escanear tudo (a menos que source_verify_checksum esteja em ON).

Esse evento é marcado como ignorável (ignorable). Qualquer consumidor de binlog que não o reconheça, réplica mais antiga, mysqlbinlog, ou uma ferramenta de change data capture como Debezium, AWS Database Migration Service (AWS DMS) ou Maxwell, simplesmente pula e continua lendo o resto da transação normalmente. Na prática, isso significa que pipelines de replicação lógica e CDC que já leem o binlog do MySQL não precisam de nenhuma mudança para continuar funcionando com o BOLT ligado.

Dois controles e um contador para auditar

O recurso é controlado por uma variável dinâmica, binlog_large_transaction_optimization_enabled, que vem ON por padrão. O limiar que decide se uma transação é "grande" é binlog_large_transaction_optimization_threshold, com 128 MB como valor padrão: acima disso, o spill file da transação é promovido em vez de copiado.

Para auditar quantas transações já foram otimizadas no servidor, existe a variável de status binlog_large_transaction_optimization_count:

mysql> SHOW GLOBAL STATUS LIKE 'binlog_large_transaction_optimization_count';
+-----------------------------------------------+-------+
| Variable_name                                  | Value |
+-----------------------------------------------+-------+
| binlog_large_transaction_optimization_count    | 42    |
+-----------------------------------------------+-------+

Quem opera RDS ou Aurora MySQL e quer saber se um pico de I/O recente veio de uma transação grande sendo promovida tem nessa variável um ponto de partida direto, sem precisar vasculhar log de erro.

Os números do benchmark da AWS

A AWS testou o BOLT num EC2 r7i.16xlarge (64 vCPUs), com dados e logs num volume gp3 de 2.048 GiB provisionado a 16.000 IOPS e 1.000 MiB/s, usando sysbench no modo oltp_read_write sobre 500 tabelas de 100 mil linhas. Os números abaixo são médias de três execuções, no próprio ambiente de teste da AWS (não medições de carga de produção de clientes).

Com o BOLT desligado, a latência de commit cresce de forma praticamente linear com o tamanho da transação, de cerca de 10 segundos em 1 GiB a cerca de 7 minutos em 50 GiB. Ligado, ela fica estável entre 2 e 2,5 segundos em todos os tamanhos testados: o tempo que sobra vai para persistir o spill file em disco durável e fechar a transação no InnoDB.

Onde isso já roda e onde ainda não

Aqui está o ponto que interessa para quem decide entre RDS for MySQL e Aurora MySQL hoje: o BOLT já está em produção. A AWS roda essa otimização internamente desde novembro de 2019, e ela está disponível e ligada por padrão no Aurora MySQL desde a versão 1.22.0, cobrindo todas as versões principais atualmente suportadas (Aurora MySQL 2.x, 3.x e 8.4.x). Não há flag para ativar: todo cliente Aurora MySQL nessas versões já se beneficia, sem mudança de aplicação.

O que ainda não aconteceu é o merge na comunidade. O BOLT foi contribuído ao MySQL community (branch trunk, outubro de 2026) e está planejado para sair numa futura innovation release do MySQL: só a partir daí RDS for MySQL e instalações self-managed de MySQL herdam o mesmo ganho. Até lá, quem roda RDS for MySQL (não Aurora) segue no caminho de commit tradicional, sujeito ao mesmo gargalo de transações grandes descrito acima.

O que isso muda na operação

Para arquitetos e times de SRE que desenham cargas de ETL, migração de dados ou jobs batch contra Aurora MySQL, o BOLT reduz dois riscos operacionais concretos: o head-of-line blocking que uma carga pesada causa em todo o resto do tráfego transacional, e o tempo de recuperação depois de um restart ou failover que pegou uma transação grande no meio do caminho. Os 4 minutos de recuperação de uma transação de 50 GiB caem para uma fração de segundo, um ganho direto de MTTR em qualquer runbook de incidente que envolva Aurora MySQL.

Isso não elimina o cuidado de desenhar a carga. A própria AWS recomenda continuar dividindo transações grandes em lotes menores sempre que a aplicação permitir, porque o BOLT resolve o commit e a recuperação, mas não resolve a replicação. Com replica_preserve_commit_order ativado, nenhuma outra transação pode confirmar na réplica até a transação grande terminar de aplicar: isso ainda gera atraso de replicação, porque reduz o paralelismo disponível no lado do replica.

Em resumo: se a sua carga mistura OLTP fino com jobs batch de carregamento em massa no mesmo cluster Aurora MySQL, o BOLT já está trabalhando a seu favor hoje, sem nenhuma mudança de configuração. Se você roda RDS for MySQL e depende de transações grandes, o ganho ainda não chegou, e dividir a carga em lotes continua sendo a única defesa disponível contra o lock de commit.

Fonte: AWS Database Blog