Erros comuns em replicação MySQL na produção.
Uma réplica com atraso de minutos parece um problema de performance. Em uma operação de pagamentos, e-commerce ou plataforma transacional, pode ser um problema de integridade, conciliação e decisão de negócio. Os erros comuns em replicação MySQL raramente começam com uma falha espetacular. Em geral, surgem de uma configuração aparentemente funcional, sem validação de carga, sem monitoramento orientado a risco e sem um procedimento claro de recuperação.
Replicação não é backup, não é alta disponibilidade por si só e não corrige decisões ruins de arquitetura. Ela é um mecanismo poderoso, mas exige disciplina operacional. Quando a camada de dados é crítica, aceitar atraso desconhecido, divergência silenciosa ou failover improvisado não é uma opção.
Por que a replicação falha em produção
O MySQL replica eventos registrados no binary log do servidor de origem para uma ou mais réplicas. Esse fluxo depende de rede, capacidade de I/O, paralelismo, formato de log, consistência inicial dos dados e compatibilidade entre versões. Basta um desses elementos ficar fora do controle para o ambiente perder previsibilidade.
O erro mais perigoso é tratar o status de replicação como uma confirmação absoluta de saúde. Ver `Replica_IO_Running` e `Replica_SQL_Running` como `Yes` é necessário, mas não suficiente. A réplica pode estar tecnicamente conectada e, ainda assim, atrasada, servindo dados defasados ou próxima de parar por falta de espaço em disco.
Em ambientes de alta criticidade, a pergunta não é apenas se a réplica está ativa. É se ela consegue cumprir o objetivo para o qual foi criada: leitura escalável, contingência, recuperação de desastre, relatórios ou failover controlado.
Erros comuns em replicação MySQL que elevam o risco
Subdimensionar I/O, CPU e armazenamento da réplica
Uma réplica não é um destino passivo. Ela lê relay logs, aplica transações, atualiza índices, grava redo logs, executa consultas locais e pode atender aplicações de leitura. Quando o servidor é dimensionado apenas para armazenar uma cópia dos dados, o atraso aparece assim que o primário recebe uma carga mais intensa.
O problema é mais frequente em tabelas com muitos índices secundários, transações extensas ou picos de escrita. Uma alteração em lote pode gerar um volume de eventos que a réplica não consegue aplicar na mesma velocidade. Se ela também estiver recebendo relatórios pesados, a competição por I/O transforma um pico transitório em backlog persistente.
A correção não se limita a aumentar máquina. É preciso medir taxa de geração de binlog, capacidade de aplicação, latência de disco, uso de CPU, pressão de buffer pool e padrão de consultas na réplica. Em alguns casos, separar réplicas de leitura das réplicas destinadas a contingência é a decisão mais segura.
Configurar replicação serial para uma carga paralela
Uma origem pode processar muitas transações simultâneas, mas uma réplica mal configurada pode aplicá-las de forma praticamente serial. O resultado é atraso crescente mesmo quando CPU e armazenamento não parecem saturados.
O paralelismo de aplicação deve ser configurado e validado de acordo com a versão do MySQL, o formato de binlog e o padrão real das transações. Não existe um número universal de workers. Ele depende do grau de conflito entre as escritas, da distribuição por schemas e do custo de cada transação.
Aumentar workers sem análise também não é uma solução automática. Se a carga concentra atualizações nas mesmas linhas ou tabelas quentes, o ganho será limitado. O caminho correto é testar sob carga representativa, observar conflitos e ajustar a arquitetura de escrita quando necessário.
Ignorar o atraso de replicação até o incidente
`Seconds_Behind_Source` é útil, mas não deve ser a única métrica. Em determinadas situações, ele pode não refletir adequadamente o atraso percebido pela aplicação. Além disso, uma métrica pontual não explica se o atraso está crescendo, estabilizado ou sendo recuperado.
Monitoramento operacional precisa correlacionar lag, idade do último evento aplicado, tamanho de relay logs, throughput de binlog, erros do canal, espaço em disco e saúde do processo de aplicação. Alertar somente quando a réplica para é tarde demais. A operação já perdeu uma camada de proteção.
Defina limites diferentes para cada finalidade. Uma réplica que alimenta busca ou relatórios pode tolerar algum atraso. Uma candidata a failover em uma operação financeira exige RPO definido e acompanhamento muito mais rigoroso. Sem esse acordo de negócio, o time técnico monitora números sem saber qual risco é aceitável.
Usar réplica atrasada como destino de leitura crítica
Enviar leituras da aplicação para uma réplica sem tratar consistência é um erro recorrente. Logo após uma escrita no primário, o usuário pode consultar a réplica e não encontrar o próprio dado. Isso gera carrinhos aparentemente vazios, status de pagamento incoerente, cadastros duplicados e falhas difíceis de reproduzir.
O desenho precisa distinguir leituras que aceitam eventual consistency daquelas que exigem leitura após escrita. Para fluxos críticos, a aplicação pode continuar lendo do primário por uma janela controlada ou usar mecanismos de espera pela posição de replicação. A escolha depende da latência tolerada, do volume e do impacto de uma resposta desatualizada.
Replicar não elimina a necessidade de contratos claros entre banco e aplicação. Se o aplicativo pressupõe consistência imediata em toda consulta, uma arquitetura com réplicas de leitura precisa ser adaptada antes de entrar em produção.
Permitir escrita direta na réplica
Uma réplica que aceita escrita administrativa, ajustes manuais ou jobs locais deixa de ser uma cópia confiável. A divergência pode não interromper o fluxo imediatamente. Ela permanece silenciosa até que um failover exponha registros diferentes, chaves ausentes ou dados que não deveriam existir.
A prevenção começa com controles simples e obrigatórios: usuários de aplicação sem permissão de escrita nas réplicas, `read_only` e `super_read_only` habilitados quando aplicável, segregação de credenciais e trilha de auditoria. Exceções de manutenção devem ser documentadas, aprovadas e revertidas ao fim da intervenção.
Também é necessário revisar ferramentas de deploy e automações. Um script que identifica o host errado pode executar DDL em uma réplica e comprometer a capacidade de recuperação do ambiente inteiro.
Tratar erros de SQL com `sql_slave_skip_counter`
Pular um evento para fazer a replicação voltar a rodar é uma ação de emergência, não um procedimento normal. O comando pode restaurar o status visual de saúde enquanto preserva a causa da divergência. Em seguida, o ambiente segue acumulando risco até o próximo failover ou até uma inconsistência atingir o cliente.
Erros de chave duplicada, tabela ausente, DDL incompatível e violação de integridade precisam de investigação. Qual transação falhou? Por que o dado já existia? Houve escrita fora do fluxo? A versão dos schemas é a mesma? A resposta define se é possível corrigir pontualmente, reconstruir a réplica ou interromper uma mudança de aplicação.
Em operações maduras, toda intervenção desse tipo gera registro do incidente, validação de consistência e ação preventiva. O objetivo não é apenas religar a réplica. É impedir que a mesma condição volte a ocorrer às três da manhã, durante um pico de negócio.
Não validar GTID, binlogs e compatibilidade de versão
GTID simplifica significativamente a identificação de transações e a reconstrução de canais, mas só entrega esse benefício quando o ambiente é configurado de forma consistente. Misturar práticas antigas baseadas em posições de arquivo com GTID parcial ou mal planejado aumenta a complexidade de recuperação.
A retenção de binary logs também merece atenção. Se uma réplica fica indisponível por mais tempo do que a janela de retenção, ela pode não conseguir retomar o fluxo e terá de ser reprovisionada. Isso consome rede, I/O, tempo de equipe e, dependendo do volume, amplia a exposição operacional.
Atualizações de versão exigem matriz de compatibilidade e teste de comportamento. Parâmetros de replicação, autenticação, formato de binlog e recursos de paralelismo podem mudar entre releases. Atualizar o primário sem um plano para as réplicas é uma forma eficiente de criar um incidente evitável.
Controles que reduzem falhas reais
Uma operação confiável combina arquitetura, monitoramento e rotina. É necessário testar o failover de forma controlada, medir o tempo de promoção, validar o redirecionamento das aplicações e confirmar se as escritas não voltam para o antigo primário. Um runbook que nunca foi exercitado é apenas documentação otimista.
Também vale executar verificações periódicas de consistência, principalmente em tabelas críticas. Checksums e ferramentas de comparação devem ser usados com cuidado para não gerar carga excessiva, mas ignorar divergência é pior. A frequência depende do RPO, do tamanho da base e da sensibilidade dos dados.
Por fim, mantenha uma linha de base operacional: atraso normal, throughput de replicação, espaço livre, tempo de rebuild e comportamento em picos. Sem histórico, cada alerta parece isolado. Com histórico, a equipe identifica degradação antes de ela virar indisponibilidade.
A HTI Tecnologia atua justamente nesse ponto: sustentação sênior 24/7 para transformar sinais precoces de degradação em ações controladas, antes que uma réplica atrasada se torne uma crise de produção. A melhor hora para validar a recuperação não é quando o primário já falhou. É quando o ambiente ainda está saudável e há espaço para corrigir o desenho.