Anteriormente, fiz a pergunta semelhante MySql Switching Masters durante o failover com log-slave-updates .
Digamos que esta é a nossa replicação atual
Além disso, tenho poucos servidores de aplicativos. Cada servidor de aplicativo se conecta diretamente ao Master 1 para INSERT e UPDATE e ao Slave[1-3] para SELECT.
Minha pergunta é como exatamente posso promover o Mestre 2 para ser um verdadeiro e único mestre. Observe a importância de que o Master 2 e todos os escravos abaixo dele são mysql 5.5 e o Master 1 é mysql 5.2
Quando alterei o IP do Master 1 para o IP do Master 2 nas configurações do aplicativo e fiz a implantação, houve um momento em que tive UPDATE e INSERTS tanto no Master 1 quanto no Master 2 , o que gerou "Duplicate entry..." no Master 2 . Depois disso, reconstruo a árvore e executo STOP SLAVE no Master 2 alguns segundos antes da implantação. Claro que perdi alguns dados, que foram inseridos no Master 1 e não replicados no Master 2 .
Então, qual é a maneira certa de fazer isso sem perder dados.
Além disso, ainda não entendi o que executar no Master 2 após o STOP SLAVE para redefinir as "configurações do slave", parece que não preciso realmente fazer isso, apenas STOP SLAVE e tudo deve estar funcionando, mas apenas para manter a ordem, quero redefinir as "configurações do escravo".
Quando você mudou o IP em seu aplicativo, todas as conexões de banco de dados que estavam abertas no momento desconheciam totalmente a mudança. Um rápido
netstat | grep -i mysql
revelaria isso em Master1 .Seria melhor fazer o cutover do IP da seguinte forma:
FLUSH HOSTS;
service mysql stop
service httpd restart
Para evitar que o aplicativo tenha que editá-lo para atribuir um novo IP, tente usar um DB VIP.
Por exemplo:
Aqui está o que você pode configurar
ip addr add 10.1.2.70/24 dev eth1
10.1.2.70
em seu aplicativoEntão, quando chegar a hora de cortar, faça o seguinte
FLUSH HOSTS;
service mysql stop
ip addr del 10.1.2.70/24 dev eth1
ip addr add 10.1.2.70/24 dev eth1
SHOW SLAVE STATUS\G
e certifique-se de que todas as instruções SQL finais do Master1 foram executadasservice httpd restart
Dessa forma, uma substituição não envolveria a edição de nenhuma parte do aplicativo. Observe que eu não mencionei a execução
STOP SLAVE
em qualquer lugar porque isso permitiria que qualquer instrução SQL final fluísse do Master1 para o Master2 quando o mysql fosse interrompido no Master1.