Por uma questão de simplicidade, recomendo apenas replicação circular do MySQL. Aqui está o porquê:
Existem muitas tecnologias e topologias que são muito superiores à replicação circular do MySQL. Meu favorito, sem dúvida , é o DRBD (Distributed Replicated Block Device) . No entanto, o DRBD funciona muito bem quando o par de servidores está no mesmo bulding, data center e rack. É ainda melhor ao usar um cabo cruzado na sub-rede 192.168.xx entre o DRBD Primário e o DRBD Secundário. Infelizmente , o DRBD tem um desempenho horrível a uma distância entre dois locais, embora o DRBD ainda possa funcionar. Não há topologias de rede disponíveis para fornecer o desempenho satisfatório de DRBD necessário entre dois datacenters.
Depois de configurar a replicação circular do MySQL entre os dois servidores de banco de dados em dois data centers diferentes, o único ajuste necessário é para a rede. Em essência, o desempenho da replicação é uma função das configurações de rede (velocidade / latência da transmissão de log binário no MySQL Replication Setup) e E / S de disco (DRBD).
Uma alternativa que você pode desejar para uma melhor redundância é a seguinte, por exemplo:
Configurar um par DRBD nos dois locais
Par DRBD no site nº 1 com VIP 111.111.111.111
Par DRBD no site nº 2 com VIP 222.222.222.222
Configure a replicação circular do MySQL entre os servidores principais DRBD sob estas condições:
Para o site 1, use 222.222.222.222 como Master_Host no MySQL.
Para o site 2, use 111.111.111.111 como Master_Host no MySQL.
Apesar de apresentar um nível de complexidade, agora você tem dois níveis de redundância: DRBD em cada site e Replicação Circular do MySQL entre sites. Você tem os benefícios adicionais de executar backups via mysqldump no DRBD Primary do servidor em espera quente.
Quanto ao failover, o DRBD fornece failover automático em qualquer site.
Somente no caso de um data center ser totalmente indisponível, você utilizaria o DB VIP no site em espera.
ATUALIZAR
Eu fiz duas vezes e notei que você está usando o Drupal6. Estou feliz que você esteja convertendo todas as tabelas drupal para o InnoDB. Isso removerá qualquer chance de atualizações da tabela MyISAM, fazendo com que os bloqueios congelem as conexões do banco de dados que estão simplesmente lendo tabelas MyISAM. Qualquer atualização DML (INSERTs, UPDATEs, DELETEs) em uma tabela MyISAM SEMPRE FECHARÁ UM BLOQUEIO DE TABELA COMPLETA !!! O uso do InnoDB apresentará o bloqueio no nível da linha, o que elimina os bloqueios completos da tabela.
Além disso, o DRBD se torna seu amigo quando tudo está no InnoDB, porque a recuperação de falhas será consistente entre o par DRBD. Por outro lado, o DRBD com MyISAM não compra nada porque uma tabela MyISAM com falha no DRBD Primary é simplesmente duplicada no DRBD Secondary como, você adivinhou , uma tabela MyISAM com falha.
ATUALIZAÇÃO # 2
Você deve usar dois níveis de redundância
Nível 1: em cada centro de banco de dados, use DRBD.
http://dev.mysql.com/doc/refman/5.1/en/ha-drbd.html
Configurar um par de servidores DB DB
Startup DRBD
MySQL no DRBD Primary
Isso cria dados redundantes no nível do disco.
Nível 2: você deve configurar a replicação circular do MySQL entre
o DRBD Primary do DataCenter # 1 e o DRBD Primary do DataCenter # 2
Cada Primário DRBD estará executando o MySQL e atuará
como Mestre e Escravo um do outro
Eu configurei para topologias de clientes como essa e considero bastante estável.
