MySQL dupla mestre

Question

Para o meu projeto atual, estamos pensando em criar uma topologia de dupla replicação mestre para uma configuração separados geograficamente; um db sobre os EUA costa leste e outro db no Japão. Estou curioso para saber se alguém já tentou isso e que há experiência tem sido.

Além disso, estou curioso o que minhas outras opções são para resolver este problema; estamos considerando filas de mensagens.

Obrigado!

Answer 1

Apenas uma nota sobre os aspectos técnicos do seu plano: Você tem que saber que o MySQL não suporta oficialmente replicação multi-mestre (somente MySQL Cluster fornece suporte para replicação síncrona).

Mas há pelo menos um "corte" que torna multi-master-replicação possível mesmo com uma configuração de replicação MySQL normal. Por favor, consulte "MySQL Multi-Master Replication" Patrick Galbraith para uma possível solução. Eu não tenho nenhuma experiência com esta configuração, então eu não me atrevo a julgar sobre como viável esta abordagem seria.

Answer 2

Há várias coisas a considerar quando se replicar bases de dados geograficamente. Se você está fazendo isso por razões de desempenho, certifique-se o seu modelo de replicação suporta seus dados sejam "finalmente consistente", uma vez que pode levar algum tempo para trazer a corrente de replicação em ambos, ou muitos, locais. Se os seus tempos de produção ou de resposta entre locais não é bom, replicação ativa pode não ser a melhor opção.

Answer 3

Configurar mysql como dupla mestre faz realmente bom trabalho no cenário direita feita corretamente. Mas não estou certo de que ele se encaixa muito bem em seu cenário.

Em primeiro lugar, a configuração mestre dupla no mysql é realmente um anel-setup. Um servidor é definido como mestre de B, enquanto que B é ao mesmo tempo definido como o mestre de A, de modo que ambos os servidores de actuar tanto como mestre e escravo. A replicação funciona enviando um log binário contendo as instruções SQL que as inserções de escravos, quando se julgue convenientes, que normalmente é de imediato. Mas se você está martelando com inserções locais, vai demorar um tempo para se recuperar. As inserções de escravos são sequenciais, a propósito, para que você não vai obter qualquer benefício de múltiplos núcleos etc.

O uso primário do mysql mestre dupla é ter redundância no nível do servidor com automático fail-over (muitas vezes usando hearbeat no linux). Excluindo mysql-cluster (por várias razões), este é o failover automático utilizável apenas para o mysql. A configuração para dupla mestre básico é facilmente encontrado na google . O material batimento cardíaco é um trabalho pouco mais. Mas isso não é realmente o que você estava perguntando sobre, uma vez que este realmente se comporta como um servidor de banco de dados único.

Se você quiser a configuração master dupla, porque você sempre quer escrever para um banco de dados local (escrita para os dois ao mesmo tempo), você precisa escrever a sua aplicação com isso em mente. Você pode nunca ter valores de autoincremento no banco de dados, e quando você tem valores exclusivos, você deve se certificar de que os dois locais nunca escrever o mesmo valor. Por exemplo localização Um poderia escrever números exclusivos ímpares e localização B poderia escrever números ainda únicas. A razão é que você não está garantido que os servidores estão em sincronia, em determinado momento, então se você tiver inserido uma linha única na A, e, em seguida, uma linha única sobreposição no B antes do segundo servidor alcança, você tem um sistema quebrado. E se algo primeiras quebras, todo o sistema pára.

Para resumir: é possível, mas você precisa ponta dos pés com muito cuidado se você está construindo software de negócios no topo desta.

Answer 4

Por causa da arquitetura de um-para-muitos de replicação do MySQL, você tem que ter um anel de replicação com vários mestres: isto é, cada repetições do seguinte em um loop. Para dois, eles replicam um do outro. Este tem sido apoiada de tão longe para trás como v3.23.

Em um lugar anterior eu trabalhava, fizemo-lo com v3.23 com um grande número de clientes como uma forma de fornecer exatamente o que você está pedindo. Usamos túneis SSH através da Internet para fazer a replicação. Levou algum tempo para obtê-lo vezes confiáveis ??e vários que tivemos de fazer uma cópia binária de um banco para outro (felizmente, nenhum deles foram mais de 2Gb nem precisava de acesso 24 horas). Também a replicação em v3 não era tão estável como em v4 mas mesmo em v5, ele vai simplesmente parar de se detectar qualquer tipo de erro.

Para acomodar o atraso replicação inevitável, nós re-estruturou o aplicativo para que ele não confiar em campos AUTOINCREMENT (e removido esse atributo das tabelas). Este foi razoavelmente simples devido à camada de acesso a dados que tínhamos desenvolvido; em vez disso usando mysql_insert_id() para novos objetos, criou o novo ID primeiro e inserido-lo junto com o resto da linha. Também implementamos IDs do local que nós armazenados na metade superior da ID, porque eles eram BIGINTs. Isso também significava que não tem que alterar a aplicação quando tivemos um cliente que queria o banco de dados em três locais. : -)

Não foi 100% robusta. InnoDB estava apenas ganhando alguma visibilidade por isso não poderia facilmente usar transações, embora nós considerado. Então havia condições de corrida, ocasionalmente, quando dois objetos tentou ser criado com o mesmo ID. Isto significou uma falha e nós tentamos relatar que no aplicativo. Mas ainda era uma parte significativa do trabalho de alguém para vigiar a replicação e corrigir as coisas quando ele quebrou. Importante, para corrigi-lo antes de chegarmos longe demais fora de sincronia, porque em alguns casos os bancos de dados estavam sendo usados ??no ambos locais e iria rapidamente tornar-se difícil voltar a integrar, se tivéssemos que reconstruir um.

Foi um bom exercício para ser uma parte, mas eu não faria isso novamente. Não em MySQL.