Solução Rápida de Falhas Comuns na Replicação MySQL

Solução Rápida de Problemas Comuns de Falha de Replicação MySQL

A replicação MySQL é um recurso poderoso que permite manter múltiplas cópias do seu banco de dados, crucial para alta disponibilidade, escalabilidade de leitura e recuperação de desastres. No entanto, configurar e manter a replicação pode, por vezes, levar a falhas inesperadas. Este guia fornece uma abordagem prática para diagnosticar e resolver rapidamente problemas comuns de replicação MySQL, focando na compreensão dos códigos de erro e na inspeção de logs relevantes.

Quando a replicação falha, pode paralisar operações críticas, por isso ter um processo sistemático de solução de problemas é essencial. Abordaremos os problemas mais frequentes, fornecendo-lhe o conhecimento para identificar a causa raiz e implementar soluções de forma eficiente. Ao compreender os sintomas e saber onde procurar pistas, pode minimizar o tempo de inatividade e garantir que a sua configuração de replicação se mantém saudável.

Noções Básicas de Replicação MySQL

Antes de mergulhar na solução de problemas, uma rápida revisão sobre como a replicação MySQL funciona é benéfica. Numa configuração típica master-slave (ou primário-réplica):

Log Binário (Binlog) no Primário: O servidor primário regista todos os eventos de alteração de dados nos seus ficheiros de log binário.
Threads de Replicação na Réplica: O servidor réplica tem duas threads (ou processos):
- Thread de I/O: Conecta-se ao primário, lê eventos do log binário do primário e escreve-os no seu próprio log de retransmissão (relay log).
- Thread SQL: Lê eventos do log de retransmissão e executa-os na base de dados da réplica.

As falhas de replicação geralmente ocorrem quando a thread de I/O não consegue obter eventos, ou a thread SQL não consegue aplicá-los.

Códigos de Erro Comuns de Replicação e Seus Significados

O MySQL fornece códigos de erro que oferecem informações valiosas sobre problemas de replicação. O comando SHOW REPLICA STATUS (ou SHOW SLAVE STATUS em versões mais antigas) é a sua ferramenta principal para verificar o estado da replicação.

SHOW REPLICA STATUS\G

Procure os seguintes campos chave:

Replica_IO_Running: Deve ser Yes (Sim).
Replica_SQL_Running: Deve ser Yes (Sim).
Last_IO_Errno e Last_IO_Error: Erros relacionados com a thread de I/O.
Last_SQL_Errno e Last_SQL_Error: Erros relacionados com a thread SQL.
Seconds_Behind_Source: Indica o atraso (lag) da réplica em relação ao primário.

Aqui estão alguns números de erro comuns e as suas causas típicas:

Erro 1062: Entrada Duplicada

Last_SQL_Errno: 1062
Last_SQL_Error: Error 'Duplicate entry '...' for key '...' on query. Default database: '...'.

Causa: A thread SQL está a tentar aplicar um evento do primário que resulta numa violação de chave duplicada na réplica. Isto acontece frequentemente quando a réplica ficou para trás e processou outras escritas que podem ter criado os mesmos dados, ou se foi introduzida manualmente uma inconsistência na réplica.

Resolução:
1. Identifique a query problemática: A mensagem de erro geralmente inclui a query que falhou.
2. Ignore a transação (com cautela): Se tiver certeza de que é seguro ignorar, pode usar SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1; seguido de START SLAVE SQL_THREAD; (ou START REPLICA SQL_THREAD;). Aviso: Ignorar transações pode levar à divergência de dados. Compreenda as implicações antes de prosseguir.
3. Investigue a inconsistência de dados: Se ignorar não for uma opção, pode ser necessário conciliar manualmente os dados ou investigar por que ocorreu a duplicação. Isso pode envolver o reinício da replicação a partir de um ponto específico se a réplica estiver seriamente dessincronizada.

Erro 1236: Não foi possível encontrar o nome do primeiro ficheiro de log no índice de log binário

Last_IO_Errno: 1236
Last_IO_Error: Error 'Could not find first log file name in binary log index' when trying to read event from the http client side...

Causa: A thread de I/O não consegue localizar o ficheiro de log binário especificado pelo primário. Isto geralmente significa que os ficheiros de log binário foram limpos do primário antes que a réplica pudesse lê-los, ou a réplica está a tentar conectar-se usando um ficheiro binlog que já não existe.

Resolução:
1. Verifique a retenção do binlog do primário: Certifique-se de que expire_logs_days (ou binlog_expire_logs_seconds) no primário está definido para um valor que retém logs tempo suficiente para a réplica acompanhar.
2. Re-inicialize a réplica: A solução mais comum é parar a replicação, redefinir os dados mestres da réplica e re-inicializá-la a partir de um backup ou snapshot recente do primário, garantindo que o novo ficheiro de log primário e a posição estão definidos corretamente.

Erro 1577: A posição do log binário do primário é obrigatória

Last_IO_Errno: 1577
Last_IO_Error: Error: The primary's binary log position is required for this operation.

Causa: Este erro ocorre tipicamente quando tenta iniciar a replicação sem especificar o nome e a posição corretos do ficheiro de log binário na réplica. Isto pode acontecer após certas alterações de configuração ou intervenções manuais.

Resolução:
1. Verifique o comando CHANGE MASTER TO (ou CHANGE REPLICATION SOURCE TO): Certifique-se de que especificou corretamente MASTER_LOG_FILE e MASTER_LOG_POS (ou SOURCE_LOG_FILE e SOURCE_LOG_POS) ao configurar a replicação.
2. Redefina e reconfigure: Pare a replicação, redefina o estado da réplica e reaplique o comando CHANGE MASTER TO com os parâmetros corretos obtidos do primário.

Erro 1032: Não é possível encontrar o registo na tabela '...'

Last_SQL_Errno: 1032
Last_SQL_Error: Error 'Can't find record in '...' table' on query. Default database: '...'.

Causa: Semelhante ao Erro 1062, isto indica que a thread SQL está a tentar executar uma operação de UPDATE ou DELETE num registo que não existe na réplica. Isto implica divergência de dados, muitas vezes devido a uma transação ignorada anteriormente ou a uma modificação manual.

Resolução:
1. Identifique a query e a tabela: A mensagem de erro fornece detalhes.
2. Investigue o desvio de dados (data drift): Compare o estado da tabela afetada no primário e na réplica.
3. Ignore (com extrema cautela): Se o registo em falta for irrelevante ou tiver sido tratado por outros meios, pode ignorar a transação usando SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1; e START REPLICA SQL_THREAD;.
4. Correção manual de dados: Em casos críticos, pode ser necessário inserir manualmente o registo em falta ou ressincronizar a tabela/base de dados.

Inspeção de Logs de Replicação

Para além de SHOW REPLICA STATUS, o log de erro do MySQL e o próprio log binário são recursos inestimáveis.

Log de Erro MySQL

Localizado tipicamente em /var/log/mysql/error.log (ou similar, dependendo do seu SO e configuração), este log contém informações detalhadas sobre erros encontrados pelo servidor MySQL, incluindo aqueles relacionados com as threads de replicação.

O que procurar:
* Rastreios de pilha (stack traces) detalhados para erros.
* Problemas de conexão entre primário e réplica.
* Timeouts e problemas relacionados com a rede.

Log Binário do Primário

Embora os logs de retransmissão da réplica sejam cruciais para a thread SQL, examinar o log binário do primário pode, por vezes, ajudar a entender a sequência de eventos que levaram a uma falha. Pode usar o utilitário mysqlbinlog para este fim.

Exemplo: Para visualizar eventos de um ficheiro de log binário específico:

mysqlbinlog /path/to/mysql-bin.000001

Exemplo: Para visualizar eventos em torno de um horário ou posição específicos:

mysqlbinlog --start-datetime="2023-10-27 10:00:00" --stop-datetime="2023-10-27 11:00:00" /path/to/mysql-bin.000001

Casos de uso:
* Compreender a transação exata que causou um erro SQL da réplica.
* Verificar a consistência dos eventos que estão a ser escritos.

Passos Gerais de Solução de Problemas

Quando a replicação falha, siga estes passos:

Verifique SHOW REPLICA STATUS: Comece sempre por aqui. É a maneira mais rápida de obter um resumo do problema.
Examine Last_IO_Error e Last_SQL_Error: Entenda o código de erro e a mensagem específicos.
Consulte o Log de Erro MySQL: Procure contexto mais detalhado no lado do servidor.
Verifique a Conectividade de Rede: Certifique-se de que a réplica pode alcançar o primário (firewalls, DNS).
Verifique os Privilégios do Utilizador: O utilizador de replicação no primário deve ter as permissões necessárias (REPLICATION SLAVE).
Garanta que o Primário está configurado para Replicação: Verifique se log_bin está ativado e se server_id é exclusivo.
Verifique a configuração read_only da Réplica: Se read_only estiver ativado na réplica, esta não aplicará escritas do primário, a menos que condições específicas sejam atendidas ou que seja temporariamente desativado.

Melhores Práticas para Prevenir Falhas

Monitorize o Atraso (Lag) da Replicação: Use ferramentas de monitorização para o alertar quando Seconds_Behind_Source crescer excessivamente.
Backups Regulares: Mantenha backups consistentes do seu primário para poder re-inicializar uma réplica rapidamente.
Retenção Suficiente de Binlog: Configure expire_logs_days adequadamente no primário.
server_id Exclusivo: Certifique-se de que cada servidor na sua topologia de replicação tem um server_id exclusivo.
Teste os Procedimentos de Failover: Pratique regularmente a troca de funções para garantir que a sua configuração de replicação é robusta.

Conclusão

A solução de problemas de falhas de replicação MySQL exige uma abordagem metódica. Ao compreender os códigos de erro comuns, saber como interpretar a saída de SHOW REPLICA STATUS e aproveitar os logs de erro do MySQL e o utilitário mysqlbinlog, pode diagnosticar e resolver eficientemente a maioria dos problemas de replicação. A monitorização proativa e a adesão às melhores práticas minimizarão ainda mais a ocorrência destes problemas, garantindo a estabilidade e a disponibilidade do seu ambiente de base de dados.