Replicación MySQL en servidores separados geográficamente

Mi organización ha estado investigando cómo distribuir nuestros servidores geográficamente mientras mantiene las copias de seguridad muy actualizadas e idealmente distribuye la carga.

Lo primero que tengo en mente es Rails en MySQL. La tasa de escritura no es demasiado alta (los artículos / comentarios se dejan a menos de 1 por minuto, aunque algunos tienen grandes archivos adjuntos).

Entonces,

• Cómo funciona la replicación MySQL en redes de área amplia?
• ¿La conexión (o un servidor esclavo) que no funciona significa que se requiere intervención manual (una vez que los dos servidores pueden comunicarse entre sí nuevamente) o que la recuperación es automática?
• Si el maestro desaparece, ¿qué se requiere para convertir un esclavo en un maestro? ¿Existen scripts / herramientas estándar para ayudar a gestionar eso?
• ¿Alguna otra trampa, etc.?

Utilizamos la replicación en centros de datos en varios países europeos (por lo que no están en todo el mundo entre sí, pero ciertamente no son locales) y funciona sin ningún problema.

La replicación se reiniciará automáticamente si es posible. Si hay un problema con una consulta (por ejemplo, una base de datos está presente en el maestro y no en el esclavo, y una consulta la usa), entonces requerirá corrección manual por defecto (pero puede configurarla para ignorar tales errores). Si las bases de datos son réplicas exactas, nunca debería necesitar reiniciar manualmente la replicación.

Si tiene dos servidores y el maestro desaparece, entonces para convertir el esclavo en el 'maestro', simplemente detenga la replicación y modifique su código (para escribir en el nuevo 'maestro'). Si tiene tres o más servidores y el maestro desaparece, detenga la replicación en los esclavos, cámbielos para usar el nuevo maestro y comience nuevamente. Si no están exactamente sincronizados (depende de la cantidad de datos que se transfieren, qué tan ocupados están los servidores, qué tan buena es la conexión de red, etc.), entonces es posible que tenga que hacer más trabajo que eso. La sección de replicación de la documentación de MySQL cubre esto con más detalle .

Sugeriría que se asegure de que está replicando a través de SSL (es decir, configure el usuario de replicación para que requiera una conexión SSL).

La replicación cambió dramáticamente en MySQL 5.1. En 5.0 solo se utilizó la replicación basada en sentencias. Ahora tiene la opción de hacer una replicación basada en filas o una replicación basada en mezclas. Esto afectará en gran medida la forma de replicar a través de una WAN.

Si tiene la capacidad de: A) Hacer el control de IP (si sus servidores están geográficamente separados, esto no es probable) B) Realizar cambios de DNS ágiles Puede evitar modificar el código / configuración de la aplicación para cambiar los maestros. Usamos DNS interno con caché corto y dominios falsos .internal. Si necesitamos cambiar masterdb.internal para que sea otro servidor, en 5 segundos el cambio propicia.

Dentro de un solo centro de datos usamos el control de IP. Todos los servidores de base de datos tienen interfaces virtuales (eth0: 1, eth0: 2, eth0: 3) que no se activan en el arranque. Si uno de los esclavos necesita hacerse cargo, usted solo tiene eth0: 2 y es el maestro. En este escenario, eth0 es el 'if' que usamos para shell y tal. Las aplicaciones se conectan en eth0: 1, que no se activará en el arranque si mi script detecta que se tomó la IP. (wikipedia STONITH) Los otros ifs son para hacerse cargo de las direcciones IP de los maestros que pueden necesitar una conmutación por error.

No recomendaría cruzar los océanos al usar una replicación MySQL. Una vez intenté replicar de un maestro en Europa mientras el esclavo estaba en Texas. La replicación se rompió casi todos los días hasta que abandonamos este proyecto. Por supuesto, puede funcionar, pero tiende a volverse más frágil cuanto mayor es la distancia entre el maestro y el esclavo.