Ressincronizar Slave MySQL sem downtime com Percona Toolkit

Recentemente, trabalhei em um caso extremo em que um slave ficou dessincronizado, mas não pôde ser reconstruído do zero porque o slave estava agindo como um servidor master para uma aplicação e havia dados sendo gravados nele. Foi um erro de projeto e isso não é recomendado, mas aconteceu. Então, o que podemos fazer neste caso para sincronizar os dados novamente? Este post descreve as etapas necessárias para se recuperar dessa situação. As ferramentas usadas para recuperar o slave foram o pt-slave-restartpt-table-checksumpt-table-sync e mysqldiff.

Para ilustrar essa situação, foi utilizada uma configuração master x slave com o sysbench em execução no servidor principal para simular uma carga de trabalho de aplicação. O ambiente foi definido com o Percona Server 5.7.24-26 e o sysbench 1.0.16.

Abaixo estão os comandos sysbench para preparar e simular a carga de trabalho:

Com o ambiente configurado, o servidor slave foi parado e algumas operações para dessincronizar o slave foram realizadas para reproduzir o problema.

Com o slave dessincronizado, um restart na replicação é executado. Imediatamente, o erro abaixo aparece:

Para recuperar o slave deste erro, é necessário apontar o slave para um binary log que exista e tenha uma posição de binary log válida. Para obter uma posição de binary log válida, o comando abaixo precisa ser executado no master:

Então, um comando CHANGE MASTER precisa ser executado no slave:

Agora o slave tem um binary log válido para ler, mas como é inconsistente, outro erro aparece:

Antes de corrigir as inconsistências, é necessário manter a replicação em execução e ignorar os erros. Para isso, a ferramenta pt-slave-restart será usada. A ferramenta precisa ser executada no servidor slave:

A ferramenta irá ignorar os erros e colocar as threads de replicação em execução. Abaixo está um exemplo da output do pt-slave-restart:

Com a ferramenta em execução em um terminal, começa a fase para verificar as inconsistências. Primeiramente, uma verificação de definição de objeto será executada usando o utilitário mysqldiff. A ferramenta mysqldiff faz parte dos utilitários do MySQL. Para executar a ferramenta:

E abaixo estão as diferenças encontradas entre o master e o slave:

1-) Uma tabela que não existe

2-) E uma estrutura de tabela inconsistente

Aplicando as recomendações no slave (criação de tabela e modificação da tabela), as definições de objeto agora são iguais. O próximo passo é verificar a consistência dos dados. Para isso, o pt-table-checksum será usado para identificar quais tabelas estão fora de sincronia. Este comando é executado no servidor master.

E um exemplo de output:

Analisando a coluna DIFFS, é possível identificar quais tabelas estão comprometidas. Com essa informação, a ferramenta pt-table-sync será usada para corrigir essas inconsistências. A ferramenta sincroniza os dados da tabela MySQL com eficiência, realizando alterações não operacionais (non-ops) no master, para que possam ser replicados e aplicados no escravo. As ferramentas precisam ser executadas no servidor slave. Abaixo está um exemplo da ferramenta em execução:

É possível realizar um dry-run antes de executar as alterações para verificar quais alterações que a ferramenta aplicará:

Depois de executar o pt-table-sync, é recomendado executar novamente o pt-table-checksum e verificar se a coluna DIFFS mostra o valor 0.

Conclusão

Este artigo foi planejado para cobrir todos os possíveis problemas que poderiam acontecer em um slave quando ele estiver dessincronizado, como operações de DDL, purga de binary log e operações DML. Esse processo envolve várias etapas e pode levar muito tempo para ser concluído, especialmente em grandes bancos de dados. Observe que esse processo pode demorar mais do que o processo de backup / restauração. No entanto, em situações como a mencionada acima, pode ser a única solução para recuperar um slave.

Leave a Reply