Replicação do MySQL em servidores geograficamente separados

Minha organização tem estudado como distribuir nossos servidores geograficamente, mantendo os backups muito 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 anexos de mídia grandes).

Então,

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

Usamos a replicação entre datacenters em vários países europeus (para que eles não fiquem espalhados pelo 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), será necessária a correção manual por padrão (mas você pode configurá-lo para ignorar esses erros). Se os bancos de dados forem espelhos exatos, você nunca precisará reiniciar manualmente a replicação.

Se você tiver dois servidores e o mestre desaparecer, para transformar o escravo no 'mestre', basta parar a replicação e alterar seu código (para gravar no novo 'mestre'). Se você tiver três ou mais servidores e o mestre desaparecer, pare a replicação nos escravos, altere-os para usar o novo mestre e inicie novamente. Se eles não estiverem exatamente sincronizados (depende da quantidade de dados que estão sendo transferidos, da ocupação dos servidores, da qualidade da 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 cobre isso com mais detalhes .

Eu sugiro que você garanta que está replicando sobre SSL (ou seja, defina o usuário de replicação para exigir uma conexão SSL).

A replicação mudou drasticamente no MySQL 5.1. Na versão 5.0, apenas a replicação baseada em instruções foi usada. Agora você tem a opção de fazer Replicação Baseada em Linha ou Replicação Mista. Isso afetará bastante a maneira como você se replica em uma WAN.

Se você puder: A) O controle de IP (se seus servidores estiverem separados geograficamente, isso não é provável) B) Faça 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 .internal falsos. Se precisarmos alterar o masterdb.internal para outro servidor, em 5 segundos a alteração se propaga.

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

Eu não recomendaria atravessar os oceanos ao usar uma replicação do MySQL. Eu tentei uma vez replicar de um mestre na Europa enquanto o escravo estava no Texas. A replicação foi interrompida quase todos os dias até abandonarmos esse projeto. Claro que pode funcionar, mas tende a ficar mais frágil quanto maior a distância entre o mestre e o escravo.