Replicação MySQL em servidores geograficamente separados

Question

Minha organização está pesquisando como distribuir geograficamente nossos servidores, mantendo os backups atualizados e, idealmente, distribuindo a carga.

A primeira coisa que tenho em mente é o Rails no MySQL. A taxa de gravação não é muito alta (artigos / comentários são deixados em menos de 1 por minuto, embora alguns tenham grandes anexos de mídia).

Então,

• a replicação do MySQL funciona bem em redes de área ampla?
• A conexão (ou um servidor escravo) diminuindo significa que a intervenção manual é necessária (uma vez que os dois servidores podem se comunicar entre si novamente) ou a recuperação é automática?
• Se o mestre desaparecer, o que é necessário para transformar um escravo em um mestre? Existem scripts / ferramentas padrão para ajudar a gerenciar isso?
• Algum outro problema, etc?

Answer 1

Usamos replicação em datacenters em vários países europeus (para que eles não fiquem do outro lado do mundo, mas certamente não são locais) e funciona sem nenhum problema.

A replicação será reiniciada automaticamente, se possível. Se houver um problema com uma consulta (por exemplo, um banco de dados está presente no mestre e não no escravo, e uma consulta o usa), ele exigirá correção manual por padrão (mas você pode defini-lo para ignorar esses erros). Se os bancos de dados forem espelhos exatos, você nunca precisará reiniciar manualmente a replicação.

Se você tem dois servidores e o mestre desaparece, então para transformar o escravo no 'mestre', simplesmente pare a replicação e altere seu código (para escrever no novo 'mestre'). Se você tiver três ou mais servidores e o mestre desaparecer, interrompa a replicação nos escravos, altere-os para usar o novo mestre e inicie novamente. Se eles não estiverem exatamente em sincronia (depende da quantidade de dados sendo transferidos, de quão ocupados os servidores estão, de quão boa é a conexão de rede, etc), talvez seja necessário fazer mais trabalho do que isso. A seção de replicação da documentação do MySQL aborda isso com mais detalhes .

Sugiro que você verifique se está replicando por SSL (ou seja, defina o usuário de replicação para exigir uma conexão SSL).

    

Answer 2

A replicação mudou drasticamente no MySQL 5.1. Em 5.0, apenas a Replicação Baseada em Instrução foi usada. Agora você tem a opção de fazer Replicação Baseada em Linha ou Replicação Baseada em Misto. Isso afetará muito a maneira como você replica por uma WAN.

Se você tiver a capacidade de: A) Fazer o IP assumir (se seus servidores estiverem separados geograficamente, isso não é provável) B) Fazer alterações de DNS ágeis Você pode evitar modificar o código / configuração do aplicativo para alterar os mestres. Usamos DNS interno com cache curto e domínios .internos falsos. Se precisarmos alterar o masterdb.internal para outro servidor, em 5 segundos a mudança é proposta.

Dentro de um único data center, usamos o controle IP. Todos os servidores de banco de dados têm interfaces virtuais (eth0: 1, eth0: 2, eth0: 3) que não são executadas na inicialização. Se um dos escravos precisa assumir o controle, você apenas precisa de eth0: 2 e é o mestre. Neste cenário, eth0 é o 'if' que usamos para shell e tal. Os aplicativos se conectam em eth0: 1, que não serão ativados na inicialização se meu script detectar que o IP foi obtido. (wikipedia STONITH) Os outros ifs são para assumir os IPs dos mestres que podem precisar ser reprovados.

    

Answer 3

Eu não recomendaria cruzar os oceanos ao usar uma replicação do MySQL. Tentei uma vez replicar de um mestre na europa enquanto o escravo estava no texas. A replicação quebrou quase todos os dias até que abandonamos este projeto. Claro que pode funcionar, mas tende a ficar mais fragil quanto maior a distância entre o mestre e o escravo.