Estratégia de failover automatizada para replicação mysql master-slave - por que isso não funcionaria?

Question

Gostaria de receber alguns comentários sobre essa estratégia de failover para alguns servidores MySQL que estou especulando para um cluster, e quero verificar se há algo óbvio que não sinto falta aqui.

Um servidor de aplicativos que se conecta a um servidor mestre mysql em operações do dia a dia e que possui um servidor mysql configurado como um escravo para fins de replicação mestre-escravo.

Se o servidor mysql falhar, quero que o aplicativo da web tente conectar-se ao mestre e, depois de n falharem nas tentativas, faça o seguinte:

• considere que o mestre não estará mais disponível
• envia um sinal para o servidor escravo para interromper a replicação
• envia um sinal para o servidor escravo para dizer que ele age como o novo mestre mysql
• comece a se conectar ao servidor novamente e trate-o como o mestre a partir de agora

Quando o aplicativo estiver ativo novamente e atendendo os usuários, eu gostaria de poder criar um novo servidor slave em segundo plano, assim que ele estiver pronto para atender às solicitações, configurar novamente a replicação mestre-escravo para fornecer o mesmo suporte de failover como antes.

Tenho certeza que isso já foi feito antes, mas não vejo nenhum guia sobre isso, então estou assumindo que deve haver alguma razão óbvia para que você não tente isso, que eu não tenha pensado ainda.

Quais são as armadilhas de usar essa abordagem para fornecer failover automatizado como este com o MySQL?

Como um aparte, eu estou ciente da replicação master-master, mas a) eu vi isso dar errado, e b) parece preocupantemente complicado demais.

Obrigado

    

Answer 1

O motivo pelo qual o failover automático não é propício tem a ver com o atraso de replicação. Se o escravo estiver atrasado e ocorrer failover, talvez você esteja gravando atualizações com chaves que ainda não existem, pois as inserções do mestre ainda não foram gravadas. Quanto mais atraso de replicação, mais isso é um problema. Na minha empresa, usamos o DRBD para failover automático, pois o servidor do DRBD em que você realiza failover é uma cópia exata do nível de disco do mestre original. como política, fazemos manual para failover para configurações mestre / escravo e mestre / mestre.

    

Answer 2

O que você quer é um cluster de alta disponibilidade e eu acho que sua abordagem sugerida parece um pouco estranha.

Uma boa maneira de conseguir isso é criar um cluster HA de Linux e sincronizar seu MySQL usando a sincronização DRDB no nível do sistema de arquivos.

Em tal configuração você tem 3 coisas:

1. A camada de mensagens do cluster (Linux-HA ou CoroSync)
2. O Gerenciador de Recursos de Cluster (Pacemaker)
3. A sincronização de disco (DRDB)

Em vez de criar muito código em seu aplicativo, você usa um endereço IP virtual que é movido para o nó ativo atual. Também você usa STONITH (Atire no Outro Nó In The Head (eu não inventei isso)) para ter certeza de que o primeiro nó está realmente morto antes de tentar assumir os recursos.

Existe um ótimo material para ler nesses links: link link link

    

Answer 3

Eu não descartaria a replicação mestre-mestre. Na verdade, o que você descreve é quase uma replicação master-master.

Dê uma olhada no MMM (Multi-Master Replication Manager para MySQL). link Ele funciona na camada mysql, então funciona muito melhor do que o cluster baseado em sistema operacional.