Em ambientes de replicação semissíncrona do MySQL, o commit de transações grandes frequentemente aciona timeouts semissíncronos 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 causa flutuações de desempenho. Para resolver esse problema, o RDS for MySQL introduziu o recurso de transmissão de binlog em tempo real. Ele 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 commit para milissegundos, garantindo alta confiabilidade dos dados e estabilidade no desempenho do serviço.
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, bloqueia a transmissão do Binlog de todas as transações subsequentes. Isso causa 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 serviço, 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 replicação assíncrona. Portanto, transações grandes podem causar dois problemas principais:
Flutuaçõ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.
Confiabilidade reduzida: 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. A gravação em um arquivo Binlog e o envio à instância réplica ocorrem 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 exceda um limiar definido, o recurso transmite continuamente os Binlog Events gerados do Binlog Cache para a instância réplica. Os eventos ficam 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 Relay Log e retornar uma confirmação. Esse design de streaming reduz o tempo de transmissão do Binlog no 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 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 que o mecanismo permaneça robusto.
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 nas instâncias primária e réplica. As alterações de 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 aparecem 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 flutuaçõ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 evita efetivamente flutuações de desempenho e rebaixamentos do modo de replicação.
