As replicações do master-master podem ser estáveis?

Question

Por que todos me dizem que o mestre mestre sempre termina em lágrimas e deve ser evitado?

    

Answer 1

Como duas pessoas não usam o termo exatamente da mesma maneira, duas pessoas não configuram os servidores exatamente da mesma forma, ninguém automatiza o failover da mesma forma, e muito poucas pessoas têm o domínio do mysql para fazer isso de uma maneira que realmente ajude o ambiente em vez de apenas adicionar complexidade.

Isso terminará em lágrimas, mas se você fizer certo, elas suas lágrimas não prejudicam seus empregadores ou clientes. E afinal de contas, não é para isso que servem os administradores?

Veja algumas das melhores leituras que você pode fazer: link
link
link

    

Answer 2

Confira o que o autor do MySQL High Performance (2ed) e as ferramentas do Maatkit tem a dizer sobre o assunto: link

Felicidades

    

Answer 3

Inevitavelmente, ambos serão atualizados de maneiras contraditórias entre as atualizações, e todo o inferno vai se soltar ... Ou pelo menos você terá um comportamento imprevisível.

Imagine um caso em que duas pessoas atualizam o mesmo registro de maneiras diferentes. Qual é o certo? Em um ambiente Master < - > Master, não há direito. Ambos os registros estão igualmente corretos. Então, ele vai passar e aplicá-las sequencialmente, causando uma inconsistência de dados.

Se você estiver usando o mysql, você também tende a acabar com problemas de bloqueio em nível de linha ... Essas linhas geralmente não são replicadas. E você tem que fazer um hack feio para contornar o problema dos campos duplicados de autonumeração (incrementos automáticos do servidor1 ímpares 1,3,5 e incrementos automáticos do servidor2 até mesmo 2,4,6).

Não é nada bonito.

    

Answer 4

Porque sempre termina em lágrimas e deve ser evitado.

Mais especificamente, a replicação do MySQL é frágil, e fazer isso duas vezes seguidas tem algum tipo de efeito exponencial no fator de falha. Além disso, uma pilha de suposições que os desenvolvedores fazem sobre o que você pode e não pode fazer em seu banco de dados desaparece de repente (como auto incremento, índices exclusivos, etc) e, em teoria, você pode treinar desenvolvedores com base nessas suposições ruins. você tem mais chances de pegar carona na lua.

Ah, e as soluções para os problemas com a replicação multimaster (como o salto automático de incremento) significam que o escalonamento pela adição de outro servidor de banco de dados é um processo infernal.

    

Answer 5

Parte do problema é que praticamente nunca há um motivo para se ter um ambiente mestre-mestre. O jeito certo de fazer as coisas é usar camadas de cache e agrupar suas gravações no banco de dados.