Em ambientes de replicação semissíncrona do MySQL, o commit de transações grandes frequentemente causa timeout semissíncrono devido à transmissão prolongada do Binlog. Esse comportamento rebaixa a replicação semissíncrona para assíncrona, reduzindo a confiabilidade dos dados. Além disso, bloqueia transações subsequentes e provoca oscilações de desempenho. Para resolver esse problema, o RDS for MySQL introduziu o recurso de transmissão de binlog em tempo real. Esse recurso transmite o Binlog de uma transação grande para a instância réplica em fluxo contínuo enquanto a transação ainda está em execução. Isso reduz o tempo de sincronização no momento do commit para milissegundos, garantindo alta confiabilidade dos dados e desempenho estável do service.
Visão geral do recurso
Contexto
O MySQL nativo utiliza um único canal para transmitir o Binlog entre as instâncias primária e réplica. Quando o Binlog de uma transação grande ocupa esse canal, ele bloqueia a transmissão do Binlog de todas as transações subsequentes. Isso gera um acúmulo de transações aguardando commit na instância primária, tornando-a temporariamente indisponível para escrita. Para evitar tempo de inatividade prolongado do service, o MySQL introduziu o parâmetro rpl_semi_sync_master_timeout. Se a instância réplica não confirmar o recebimento do Binlog dentro do tempo especificado, a replicação semissíncrona é rebaixada para assíncrona. Portanto, transações grandes podem causar dois problemas principais:
Oscilações de desempenho: A instância fica indisponível para escrita por vários segundos, e muitas solicitações de commit são registradas como consultas SQL lentas.
Redução da confiabilidade: O modo de replicação é rebaixado, o que pode levar à perda de dados em casos extremos.
Transmissão de binlog em tempo real
No modelo tradicional, o Binlog de uma transação é armazenado em buffer no Binlog Cache da instância primária durante a execução. Ele é gravado em um arquivo de Binlog e enviado à instância réplica somente quando a transação faz commit. O recurso de transmissão de binlog em tempo real do RDS for MySQL otimiza esse processo. Para qualquer transação grande que ultrapasse um limiar definido, o recurso transmite continuamente os Binlog Events gerados do Binlog Cache para a instância réplica. Os eventos são armazenados temporariamente em um Relay Log Cache dedicado. Quando a transação faz commit na instância primária, apenas um comando final de commit é enviado. A instância réplica pode então gravar imediatamente os dados em cache em seu arquivo de Relay Log e retornar uma confirmação. Esse design de transmissão reduz o tempo de envio do Binlog no momento do commit de segundos para milissegundos, eliminando efetivamente os gargalos de transmissão.
Princípio técnico: O design do Relay Log Cache
Para armazenar temporariamente os Binlog Events transmitidos na instância réplica, o RDS for MySQL cria um Relay Log Cache dedicado para cada transação grande. Antes de gravar os dados, o sistema reserva espaço no início do cache para preencher posteriormente o cabeçalho do Relay Log Event. Isso permite uma conversão rápida do cache para o arquivo de Relay Log. O sistema lida inteligentemente com casos em que o espaço reservado é insuficiente ou excessivo, revertendo para a lógica original ou preenchendo com um Empty Event, garantindo a robustez do mecanismo.
Aplicabilidade
Este recurso requer uma das seguintes versões de banco de dados:
MySQL 8.4
MySQL 8.0 com versão secundária do mecanismo 20250531 ou posterior
Instruções
Ative este recurso definindo os seguintes parâmetros globais tanto na instância primária quanto na réplica. As alterações nos parâmetros entram em vigor imediatamente, sem necessidade de reiniciar a instância.
-
Para ativar o recurso:
Na instância primária:
loose_binlog_realtime_transmit_source_enabled=ONNa instância réplica:
loose_binlog_realtime_transmit_replica_enabled=ON
-
Parâmetro principal:
loose_binlog_realtime_transmit_long_transaction_limit_sizeFinalidade: Especifica o limiar de tamanho de uma transação que aciona a transmissão em tempo real. Quando o Binlog gerado por uma transação excede esse tamanho, o recurso é ativado automaticamente.
Valor padrão: 128 MB.
Benefícios
Simulamos um cenário de alta carga executando uma transação grande de 2 GB em uma instância com replicação semissíncrona. Os resultados do teste são mostrados na figura a seguir:
Antes da otimização (MySQL nativo): Após o commit da transação grande, as Consultas Por Segundo (QPS) da instância caem para zero, indicando oscilações severas de desempenho. Posteriormente, o sistema é rebaixado para o modo assíncrono devido a um timeout semissíncrono. Embora o desempenho se recupere, a confiabilidade dos dados fica comprometida.
Após a otimização (RDS for MySQL): Com a transmissão de binlog em tempo real ativada, o QPS da instância permanece estável mesmo durante o commit da transação grande. Isso previne efetivamente oscilações de desempenho e rebaixamentos do modo de replicação.
