En aras de la simplicidad, solo recomiendo MySQL Circular Replication. Aquí es por qué:
Existen muchas tecnologías y topologías que son muy superiores a la replicación circular de MySQL. Mi favorito, sin lugar a dudas , es DRBD (Distributed Replicated Block Device) . Sin embargo, DRBD funciona muy bien cuando el par de servidores está en el mismo edificio, centro de datos y bastidor. Es aún mejor cuando se utiliza un cable cruzado en la subred 192.168.xx entre DRBD Primary y DRBD Secondary. Desafortunadamente , DRBD tiene un rendimiento horrible en una distancia entre dos ubicaciones, aunque DRBD aún puede funcionar. No existen topologías de red para brindarle el rendimiento DRBD satisfactorio que se necesita entre dos centros de datos.
Una vez que configura la replicación circular MySQL entre los dos servidores de base de datos en dos centros de datos diferentes, el único ajuste necesario es para la red. En esencia, el rendimiento de la replicación es una función de la configuración de la red (velocidad / latencia de la transmisión de registros binarios en la configuración de replicación MySQL) y la E / S de disco (DRBD).
Una alternativa que puede desear para una mejor redundancia es la siguiente, por ejemplo:
Configure un par DRBD en ambos lugares
Par DRBD en el sitio n. ° 1 con VIP 111.111.111.111
Par DRBD en el sitio n. ° 2 con VIP 222.222.222.222
Configure la replicación circular MySQL entre los servidores primarios DRBD en estas condiciones:
Para el sitio # 1, use 222.222.222.222 como Master_Host en MySQL
Para el sitio # 2, use 111.111.111.111 como Master_Host en MySQL
Aunque presenta un nivel de complejidad, ahora tiene dos niveles de redundancia: DRBD dentro de cada sitio y MySQL Circular Replication entre sitios. Tiene los beneficios adicionales de ejecutar copias de seguridad a través de mysqldump en el DRBD primario del servidor en espera activo.
En cuanto a la conmutación por error, DRBD proporciona conmutación por error automática en cualquier sitio.
Solo en el caso de que un centro de datos no esté totalmente disponible, usaría el DB VIP en el sitio de espera activa.
ACTUALIZAR
Acabo de hacer una doble toma y noté que estás usando Drupal6. Me alegra que convierta todas las tablas de drupal a InnoDB. Esto eliminará cualquier posibilidad de que las actualizaciones de la tabla MyISAM provoquen que los bloqueos de la tabla congelen las conexiones DB que simplemente están leyendo las tablas MyISAM. ¡Cualquier actualización DML (INSERTOS, ACTUALIZACIONES, DELETES) contra una tabla MyISAM SIEMPRE HARÁ UN BLOQUEO DE TABLA COMPLETA! El uso de InnoDB introducirá el bloqueo a nivel de fila, lo que elimina los bloqueos completos de la tabla.
Además, DRBD se convierte en tu amigo cuando todo es InnoDB porque la recuperación de fallos será coherente entre el par DRBD. Por el contrario, DRBD con MyISAM no le compra nada porque una tabla MyISAM bloqueada en la Primaria DRBD simplemente está duplicada en la Secundaria DRBD como, lo adivinó , una tabla MyISAM bloqueada.
ACTUALIZACIÓN # 2
Debes usar dos niveles de redundancia
Nivel 1: en cada centro de base de datos, use DRBD.
http://dev.mysql.com/doc/refman/5.1/en/ha-drbd.html
Configurar un par de servidores DB
Startup DRBD
Startup MySQL en el DRBD Primary
Esto crea datos redundantes a nivel de disco.
Nivel 2: debe configurar la replicación circular de MySQL entre
DRBD Primary of DataCenter # 1 y DRBD Primary of DataCenter # 2
Cada DRBD primario ejecutará MySQL y actuará
como maestro y esclavo entre sí
Tengo una configuración para topologías de clientes como esta y la considero bastante estable.
