Entendendo a Replicação MySQL

A replicação MySQL permite que dados de um servidor de banco de dados (o primário, historicamente chamado de “master”) sejam automaticamente copiados para um ou mais servidores adicionais (réplicas, historicamente chamadas de “slaves”). Este mecanismo fornece benefícios críticos: alta disponibilidade, escalamento de leitura, distribuição geográfica e descarga de backups.

Apesar de sua maturidade, a replicação MySQL está longe de ser “configure e esqueça”. Desvios de configuração, mudanças de esquema, discrepâncias de hardware e instabilidades de rede conspiram para produzir falhas de replicação que podem cascatear em inconsistências de dados, erros de aplicação e até mesmo tempo de inatividade.

Este guia cobre os problemas mais comuns de replicação MySQL, suas causas raiz e soluções passo a passo para topologias de replicação baseadas em log binário tradicional e GTID.

Pré-requisitos

  • Uma configuração funcional de primário/réplica MySQL (MySQL 5.7+ ou MySQL 8.0+).
  • Acesso shell a ambos os servidores, primário e réplica.
  • Privilégios suficientes (SUPER ou REPLICATION CLIENT) para executar SHOW SLAVE STATUS.
  • Familiaridade com SQL básico e ferramentas de linha de comando Linux.
  • Opcional: Percona Toolkit instalado para diagnósticos avançados.

Problemas Comuns de Replicação

Os cinco modos de falha a seguir representam a grande maioria dos problemas de replicação MySQL:

  1. Atraso da Réplica (Seconds_Behind_Master > 0): A réplica não consegue aplicar eventos do log binário tão rápido quanto o primário os produz.
  2. Erros de Chave Duplicada (Error 1062): Uma linha que já existe na réplica está sendo inserida novamente por uma transação replicada.
  3. Erros de Linha Ausente (Error 1032): Um UPDATE ou DELETE replicado referencia uma linha que não existe na réplica.
  4. Corrupção do Relay Log: O arquivo de relay log na réplica torna-se ilegível devido a erros de disco, falhas ou desligamentos inadequados.
  5. Divergência GTID: Na replicação baseada em GTID, o conjunto de GTIDs executados da réplica não forma mais um superconjunto contíguo do que o primário espera.

Solução Passo a Passo

1. Avaliar o Status Atual de Replicação

Sempre comece inspecionando a saúde da réplica. No servidor réplica, execute:

SHOW REPLICA STATUS\G

Para versões do MySQL anteriores a 8.0.22, use SHOW SLAVE STATUS\G.

Campos chave para inspecionar:

CampoValor SaudávelSignificado
Replica_IO_RunningYesO thread I/O está conectado ao primário e lendo logs binários
Replica_SQL_RunningYesO thread SQL está aplicando eventos do relay log
Seconds_Behind_Source0Sem atraso de replicação
Last_Error(vazio)Sem erros encontrados

Se qualquer thread mostrar No, foque nos campos de erro correspondentes: Last_IO_Error para problemas de I/O, Last_SQL_Error para falhas do lado de aplicação.

2. Corrigir o Atraso da Réplica

Atraso da réplica significa que o thread SQL não consegue acompanhar os eventos entrantes do log binário. Diagnostique com:

watch -n 1 "mysql -e 'SHOW REPLICA STATUS\G' | grep -E 'Seconds_Behind|Exec_Source_Log_Pos|Read_Source_Log_Pos'"

Causas comuns e soluções:

A) Consultas lentas na réplica:

SET GLOBAL slow_query_log = 1;
SET GLOBAL long_query_time = 1;
SET GLOBAL slow_query_log_file = '/var/log/mysql/replica-slow.log';

B) Aplicação SQL de thread único (MySQL 5.6 e anteriores):

Atualize para MySQL 5.7+ ou 8.0+ e habilite a replicação multi-thread:

STOP REPLICA;
SET GLOBAL replica_parallel_workers = 4;
SET GLOBAL replica_parallel_type = 'LOGICAL_CLOCK';
START REPLICA;

C) Gargalo de hardware: O I/O de disco da réplica está saturado. Monitore com iostat -x 1 e considere atualizar para SSDs.

3. Resolver Erros de Chave Duplicada (Error 1062)

Para replicação baseada em log binário:

STOP SLAVE;
SET GLOBAL sql_slave_skip_counter = 1;
START SLAVE;

Para replicação baseada em GTID:

STOP REPLICA;
SET GTID_NEXT = '3E11FA47-71CA-11E1-9E33-C80AA9429562:42';
BEGIN; COMMIT;
SET GTID_NEXT = 'AUTOMATIC';
START REPLICA;

Aviso: Pular transações pode introduzir desvio de dados. Sempre valide com pt-table-checksum depois.

4. Resolver Erros de Linha Ausente (Error 1032)

Quando a réplica não encontra a linha referenciada por um UPDATE ou DELETE replicado:

-- No PRIMÁRIO:
SELECT * FROM mydb.mytable WHERE id = 12345;
-- Na RÉPLICA: comparar
SELECT * FROM mydb.mytable WHERE id = 12345;

Se a linha genuinamente deveria existir na réplica, insira-a manualmente e reinicie a replicação.

5. Recuperar de Corrupção do Relay Log

STOP REPLICA;
RESET REPLICA;
START REPLICA;

Para replicação baseada em posição de log binário, especifique a posição correta:

STOP SLAVE;
RESET SLAVE;
CHANGE MASTER TO
  MASTER_LOG_FILE = 'mysql-bin.000042',
  MASTER_LOG_POS = 154;
START SLAVE;

6. Corrigir Divergência GTID

A divergência GTID ocorre quando a réplica tem transações não presentes no primário. Diagnostique com:

SELECT @@gtid_executed;
  • Divergência menor: Injete transações vazias no primário para os GTIDs extras.
  • Divergência maior: Reconstrua a réplica a partir de um backup fresco do primário usando mysqldump --single-transaction --source-data=2 ou xtrabackup.

Prevenção e Melhores Práticas

  • Torne as réplicas somente leitura: Configure read_only = 1 e super_read_only = 1 em todas as réplicas.
  • Use replicação GTID: Simplifica enormemente failover, re-apontar réplicas e pular transações.
  • Monitore o atraso de replicação continuamente: Use Percona Monitoring and Management, Prometheus com mysqld_exporter, ou integração MySQL do Datadog.
  • Execute pt-table-checksum semanalmente: Detecte proativamente desvio de dados.
  • Automatize o failover cuidadosamente: Ferramentas como Orchestrator, MHA, ou MySQL InnoDB Cluster fornecem failover automatizado.

Resumo

  • Falhas de replicação MySQL tipicamente se resumem a atraso, erros de linhas duplicadas/ausentes, corrupção do relay log ou divergência GTID.
  • Sempre inicie o diagnóstico com SHOW REPLICA STATUS e inspecione os campos Replica_IO_Running, Replica_SQL_Running e Last_Error.
  • Use sql_slave_skip_counter ou transações GTID vazias para passar erros individuais, mas sempre valide a consistência de dados depois.
  • Previna problemas impondo read_only nas réplicas, usando replicação GTID e monitorando continuamente.

Artigos Relacionados