Em uma configuração mestre-escravo do MySQL 5.7 que usa a configuração de replicação semisíncrona padrão para rpl_semi_sync_master_wait_point , uma falha do mestre e o failover para o escravo são considerados sem perdas. No entanto, quando o mestre travado voltar, você poderá descobrir que ele possui transações que não estão presentes no mestre atual (que anteriormente era um escravo). Esse comportamento pode ser intrigante, já que a replicação semisíncrona deve ser sem perdas, mas na verdade esse é um comportamento esperado no MySQL. Por que exatamente isso acontece é explicado em detalhes na postagem do blog de Jean-François Gagné (JF).
Dado tal cenário, a documentação do MySQL recomenda que o mestre travado deve ser descartado e não deve ser reiniciado. No entanto, descartar um servidor como esse é caro e ineficiente. Nesta postagem do blog, explicaremos uma abordagem para detectar e corrigir transações no servidor mestre MySQL com falha em uma configuração de replicação semissíncrona e como escravizá-lo novamente em sua configuração mestre-escravo.
Por que é importante detectar transações extras no mestre recuperado?
As transações extras no mestre recuperado podem se manifestar de duas maneiras:
1. Falhas de replicação do MySQL quando o mestre recuperado é reescravizado
Normalmente, isso acontece quando você tem uma chave primária de incremento automático. Quando o novo mestre MySQL insere uma linha em tal tabela, a replicação falhará porque a chave já existe no escravo.
Outro cenário é quando seu aplicativo tenta novamente a transação que falhou durante a falha principal. No mestre MySQL recuperado (que agora é um escravo), essa transação realmente existiria e, novamente, resultaria em um erro de replicação.
Normalmente, o erro de replicação do MySQL seria assim:
| [ERROR] Slave SQL for channel '':Worker 5 falhou ao executar a transação 'fd1ba8f0-cbee-11e8- b27f-000d3a0df42d:5938858' no log mestre mysql-bin.000030, end_log_pos 10262184; Erro 'Entrada duplicada '5018' para chave 'PRIMARY'' na consulta. Banco de dados padrão:'teste'. Consulta:'inserir nos valores de teste (5018,2019,'item100')', Error_code:1062 |
2. Inconsistência silenciosa nos dados entre o novo mestre e escravo do MySQL (mestre recuperado)
Nos casos em que o aplicativo não tenta novamente a transação com falha e não há colisões de chave primária no futuro, um erro de replicação pode não ocorrer. Como resultado, a inconsistência de dados pode não ser detectada.
Em ambos os casos acima, tanto a alta disponibilidade quanto a integridade dos dados de sua configuração do MySQL são afetadas, e é por isso que é tão importante detectar essa condição o mais cedo possível.
Como detectar transações extras no MySQL Master recuperado
Podemos detectar se há alguma transação extra no mestre recuperado usando a função MySQL GTID (identificador global de transação):
GTID_SUBSET(conjunto1 ,conjunto2 ):dados dois conjuntos de IDs de transação globais set1 e conjunto2 , retorna true se todos os GTIDs em set1 também estão em conjunto2 . Retorna false caso contrário.
Vamos usar um exemplo para entender isso.
- GTID definido no mestre recuperado cujo UUID é:‘54a63bc3-d01d-11e7-bf52-000d3af93e52 ’ é:
- '54a63bc3-d01d-11e7-bf52-000d3af93e52:1-9700,57956099-d01d-11e7-80bc-000d3af97c09:1-810'
- O conjunto GTID do novo mestre cujo UUID é:‘57956099-d01d-11e7-80bc-000d3af97c09 ’ é:
- '54a63bc3-d01d-11e7-bf52-000d3af93e52:1-9690,57956099-d01d-11e7-80bc-000d3af97c09:1-870'
Agora, se chamarmos a função GTID_SUBSET como GTID_SUBSET(conjunto GTID do mestre recuperado, conjunto GTID do novo mestre) , o valor de retorno será verdadeiro, somente se o mestre recuperado não tiver nenhuma transação extra. Em nosso exemplo acima, como o mestre recuperado possui transações extras de 9691 a 9700, o resultado da consulta acima é falso.
Re-escravizando um servidor mestre #MySQL com falha na configuração de replicação semisíncronaClique para tweet
Como re-escravizar o MySQL Master recuperado que possui transações extras
Com base na etapa acima, é possível saber se o mestre recuperado possui transações extras e quais são essas transações usando a função GTID:GTID_SUBTRACT(GTID set of mestre recuperado, conjunto GTID do novo mestre).
Também é possível extrair essas transações extras dos logs binários e salvá-las. Pode ser útil para sua equipe comercial revisar posteriormente essas transações para garantir que não estamos perdendo inadvertidamente nenhuma informação comercial importante, mesmo que não tenha sido confirmada. Feito isso, precisamos de uma maneira de nos livrar dessas transações extras para que o mestre recuperado possa ser reescravizado sem problemas.
Uma das maneiras mais simples de fazer isso é tirar um instantâneo de backup no mestre atual e restaurar os dados no escravo atual. Lembre-se de que você precisa manter o UUID deste servidor como antes. Depois de restaurar os dados, o servidor pode ser reescravizado e iniciará a replicação a partir do ponto do instantâneo restaurado. Em breve você terá um escravo saudável funcionando novamente!
As etapas acima são muito tediosas se você precisar executá-las manualmente, mas o serviço de hospedagem MySQL totalmente gerenciado do ScaleGrid pode automatizar todo o processo para você sem qualquer intervenção necessária. Veja como funciona:
Se o seu mestre atual travar, o ScaleGrid automatiza o processo de failover e promove um escravo adequado como o novo mestre. O antigo mestre é então recuperado e detectamos automaticamente se há transações extras nele. Se algum for encontrado, a implantação do MySQL é colocada em um estado degradado e usamos ferramentas automatizadas para extrair e salvar as transações extras para sua análise. Nossa equipe de suporte pode restaurar o antigo mestre para um bom estado e escravizá-lo novamente em sua configuração mestre-escravo para que você tenha uma implantação saudável!
Quer experimentar? Inicie uma avaliação gratuita de 30 dias para explorar todos os recursos de gerenciamento de banco de dados MySQL no ScaleGrid.
