Réplica quebrada / ressincronização necessária
A sincronização entre a réplica/standby e o primário está quebrada. Determine se a replicação parou, quão atrasada está e se a cadeia de posição/GTID está quebrada; depois siga o caminho certo entre pular um erro, esperar ou reconstruir (reseed). Inclui um alerta de split-brain.
Qual é o estado geral da replicação?
Primeiro leia a saúde da replicação: as threads de aplicação estão rodando, qual o tamanho do lag, há algum erro? Verifique também se os dois nós não estão ambos aceitando gravações (split-brain).
SHOW REPLICA STATUS\G
-- Check: Replica_IO_Running, Replica_SQL_Running, Seconds_Behind_Source, Last_Error, Retrieved/Executed_Gtid_Set- A replicação parou / está falhando
- Rodando, mas muito atrasada (lag grande)
- GTID/posição quebrados, inconsistente — reconstruir
- Ambos os nós estão gravando como primário (suspeita de split-brain)
O erro pode ser reparado, ou é necessária uma reconstrução?
Examine o erro de aplicação. Alguns erros (chave duplicada, linha ausente) podem ser resolvidos pulando com segurança um único evento; mas, se houver inconsistência/corrupção de dados, o único caminho correto é reconstruir a réplica.
SHOW REPLICA STATUS\G
-- Check: Last_SQL_Errno, Last_SQL_Error, Last_IO_Errno, Last_IO_Error- Um ou poucos erros de aplicação (podem ser pulados)
- Inconsistência / corrupção irreparável
O lag é temporário ou persistente?
Observe a tendência do lag ao longo do tempo. Ele se fecha (alcança o primário) após um pico temporário de carga, ou continua crescendo de modo que a réplica nunca alcança o primário?
SHOW REPLICA STATUS\G
-- Measure Seconds_Behind_Source several times: is it decreasing or increasing?- Pico temporário de carga; o lag está diminuindo
- Continua crescendo; não consegue alcançar
Solução: pule o erro de aplicação com cuidado
Se a replicação parou em um único erro de aplicação (ex.: chave duplicada) e você tem certeza de que os dados estão de fato consistentes, pode pular esse evento e continuar o fluxo. É um último recurso; pular às cegas cria divergência silenciosa de dados.
Solução: reconstrua a réplica (reseed / rebuild)
Se a cadeia de posição/GTID estiver quebrada, os dados tiverem divergido ou houver um erro irreparável, o único caminho confiável é reconstruir a réplica a partir de uma cópia nova obtida do primário.
Causa raiz: pico temporário de carga (o lag está diminuindo)
A replicação está saudável; o lag se abriu por causa de uma rajada temporária de gravações no primário ou de oscilação da rede, mas a réplica está alcançando.
Causa raiz: a réplica não consegue acompanhar o primário
O lado de aplicação (apply/redo) não consegue acompanhar o ritmo de alterações gerado pelo primário; o lag continua crescendo. Geralmente é aplicação single-thread, hardware lento na réplica ou gargalo de rede.
ALERTA: split-brain (dois primários) — risco de perda de dados
Se os dois nós aceitarem gravações no papel de primário, alterações conflitantes se acumulam nos dois lados; esta é a situação mais perigosa e pode levar à perda de dados. Reduzir as gravações a um único nó vem em primeiro lugar.