Nesta série de blogs de três partes, apresentamos uma estrutura de alta disponibilidade (HA) para hospedagem MySQL na Parte I e discutimos os detalhes da replicação semissíncrona do MySQL na Parte II. Agora, na Parte III, revisamos como a estrutura lida com alguns dos importantes cenários de falha do MySQL e se recupera para garantir alta disponibilidade.
Cenários de falha do MySQL
Cenário 1 – MySQL mestre fica inativo
- A estrutura Corosync e Pacemaker detecta que o MySQL mestre não está mais disponível. O Pacemaker rebaixa o recurso mestre e tenta se recuperar com uma reinicialização do serviço MySQL, se possível.
- Neste ponto, devido à natureza semisíncrona da replicação, todas as transações confirmadas no mestre foram recebidas por pelo menos um dos escravos.
- O Pacemaker espera até que todas as transações recebidas sejam aplicadas nos escravos e permite que os escravos relatem suas pontuações de promoção. O cálculo da pontuação é feito de forma que a pontuação seja '0' se um escravo estiver completamente sincronizado com o mestre e, caso contrário, seja um número negativo.
- O Pacemaker escolhe o escravo que relatou a pontuação 0 e promove esse escravo que agora assume o papel de mestre MySQL no qual as gravações são permitidas.
- Após a promoção do slave, o Resource Agent aciona um módulo de redirecionamento de DNS. O módulo atualiza a entrada DNS do proxy com o endereço IP do novo mestre, facilitando assim que todas as gravações do aplicativo sejam redirecionadas para o novo mestre.
- O Pacemaker também configura os escravos disponíveis para iniciar a replicação a partir deste novo mestre.
Assim, sempre que um MySQL mestre cair (seja devido a uma falha do MySQL, falha do SO, reinicialização do sistema, etc.), nossa estrutura de alta disponibilidade o detecta e promove um escravo adequado para assumir o papel de mestre. Isso garante que o sistema continue disponível para os aplicativos.
Explicação da estrutura de alta disponibilidade do #MySQL – Parte III:Cenários de falhaClique para tweet
Cenário 2 – MySQL escravo fica inativo
- A estrutura Corosync e Pacemaker detecta que o MySQL escravo não está mais disponível.
- O Pacemaker tenta recuperar o recurso tentando reiniciar o MySQL no nó. Se aparecer, ele é adicionado de volta ao mestre atual como escravo e a replicação continua.
- Se a recuperação falhar, o Pacemaker informa que o recurso está inativo – com base em quais alertas ou notificações podem ser gerados. Se necessário, a equipe de suporte do ScaleGrid cuidará da recuperação desse nó.
- Neste caso, não há impacto na disponibilidade dos serviços MySQL.
Cenário 3 – Partição de rede – A conectividade de rede é interrompida entre os nós mestre e escravo
Este é um problema clássico em qualquer sistema distribuído onde cada nó pensa que os outros nós estão inativos, enquanto na realidade, apenas a comunicação de rede entre os nós é interrompida. Esse cenário é mais comumente conhecido como cenário de cérebro dividido e, se não for tratado adequadamente, pode levar a mais de um nó alegando ser um MySQL mestre, o que, por sua vez, leva a inconsistências e corrupção de dados.
Vamos usar um exemplo para revisar como nossa estrutura lida com cenários de cérebro dividido no cluster. Assumimos que devido a problemas de rede, o cluster foi particionado em dois grupos – mestre em um grupo e 2 escravos no outro grupo, e denotaremos isso como [(M), (S1,S2)].
- O Corosync detecta que o nó mestre não consegue se comunicar com os nós escravos, e os nós escravos podem se comunicar entre si, mas não com o mestre .
- O nó mestre não poderá confirmar nenhuma transação, pois a replicação semissíncrona espera reconhecimento de pelo menos um dos escravos antes que o mestre possa confirmar. Ao mesmo tempo, o Pacemaker encerra o MySQL no nó mestre devido à falta de quorum com base na configuração do Pacemaker 'no-quorum-policy =stop'. Quorum aqui significa a maioria dos nós, ou dois em cada três em uma configuração de cluster de 3 nós. Como há apenas um nó mestre em execução nesta partição do cluster, a configuração no-quorum-policy é acionada levando ao desligamento do MySQL mestre.
- Agora, o Pacemaker na partição [(S1), (S2)] detecta que não há mestre disponível no cluster e inicia um processo de promoção. Supondo que S1 esteja atualizado com o mestre (conforme garantido pela replicação semissíncrona), ele é promovido como o novo mestre.
- O tráfego do aplicativo será redirecionado para este novo nó MySQL mestre e o S2 escravo começará a replicar a partir do novo mestre.
Assim, vemos que a estrutura MySQL HA lida com cenários de cérebro dividido de forma eficaz, garantindo consistência e disponibilidade de dados no caso de a conectividade de rede ser interrompida entre os nós mestre e escravo.
Isso conclui nossa série de blogs de 3 partes sobre a estrutura de alta disponibilidade (HA) do MySQL usando replicação semissíncrona e a pilha Corosync mais Pacemaker. Na ScaleGrid, oferecemos hospedagem altamente disponível para MySQL na AWS e MySQL no Azure que é implementada com base nos conceitos explicados nesta série de blogs. Visite o Console do ScaleGrid para uma avaliação gratuita de nossas soluções.
