
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:
- Resiliência - 2 de 3 servidores podem ficar inativos e os usuários ainda podem fazer login e ver seus dados/fazer seu trabalho
- Backup - mais ou menos como acima
- 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.