replicação mestre-mestre mySQL

replicação mestre-mestre mySQL

Eu tenho um cluster mySQL/PHP/Apache de 3 servidores (cada um em continentes diferentes para máxima resiliência). Eu li muitos conselhos que dizem: não faça isso!

Essencialmente, os motivos pelos quais quero fazer isso são:

  1. Resiliência - 2 de 3 servidores podem ficar inativos e os usuários ainda podem fazer login e ver seus dados/fazer seu trabalho
  2. Backup - mais ou menos como acima
  3. Compartilhamento de carga - posso distribuir a carga front-end E os processos do servidor back-end entre as diferentes caixas

Eu olhei para diferentes opções, incluindo percona galera, todas parecem ter desvantagens. O principal é a transparência - em algum momento um link ou servidor irá cair, então você receberá erros vagos de BINLOG, então tudo será um grande problema...

Então, eu mesmo implementei isso - tenho um conjunto de scripts que criam gatilhos INSERT/UPDATE/DELETE em cada tabela - quaisquer alterações são registradas em uma tabela de replicação. Um processo a cada minuto envia essas alterações para os outros 2 servidores. Também possuo processos que verificam o CHECKSUM e alertam sobre eventuais discrepâncias.

Funciona muito bem. Não é fácil, eu garanto! Várias coisas complicadas, incluindo:

  • não usar o tipo de coluna flutuante (0,3434 não é igual a 0,3434...)
  • evitando chaves de incremento automático (se os dados forem inseridos em 2 servidores diferentes ao mesmo tempo, ambos poderão assumir o próximo valor, então as inserções recíprocas falharão).
  • lembre-se de executar novamente o script de criação de gatilhos se você alterar a estrutura de uma tabela

Então, minha pergunta é... O que poderia dar errado? Onde/por que isso vai falhar? O que eu não sei??

Responder1

Ao contrário do que foi dito acima, acho que esta é uma excelente pergunta. Eles não estão pedindo uma análise do que fizeram, apenas a “quarta janela” geral do que são as incógnitas desconhecidas.

Aplicações com uso intensivo de dados são umaexcelente livro Eles chamam isso de replicação multilíder em vez de mestre-mestre e discutem bem por que isso apresenta armadilhas. Como você viu, os serviços com Galera e Percona não funcionam - então deve haver uma boa razão (ainda não joguei com Blackhole).

Acho que a mensagem principal é que você precisa garantir que a estrutura da tabela possa lidar com a replicação multi-lead - portanto, se 2 novas entradas forem adicionadas em servidores separados, você não iria querer (como você diz) ter uma chave de incremento automático campo - você precisa ter projetado a tabela e o aplicativo para usar talvez o ID do usuário e o carimbo de data / hora, etc ... (isso é um trabalho manual).

Você provavelmente também precisará de ferramentas decentes para poder comparar rapidamente tabelas em bancos de dados e detectar inconsistências.

informação relacionada