Estrategia automatizada de conmutación por error para la replicación Mysql maestro-esclavo – ¿por qué esto no funcionaría?

Quisiera algunas sugerencias acerca de esta estrategia de conmutación por error para un par de serveres MySQL que estoy diseñando para un clúster, y quiero comprobar si hay algo obvio que no faltan aquí.

Un server de aplicación que se conecta a un server maestro mysql en las operaciones del día a día y que tiene un server mysql configurado como esclavo para propósitos de replicación maestro-esclavo.

Si el server mysql falla, quiero que la aplicación web intente conectarse al maestro y, a continuación, después de n bashs fallidos, realice lo siguiente:

  • asumir que el master ya no estará disponible
  • enviar una señal al server esclavo para detener la replicación
  • enviar una señal al server esclavo para decirle que actúe como el nuevo maestro mysql
  • comenzar a conectar con el server de nuevo, y tratarlo como el maestro de ahora en adelante

Una vez que la aplicación está de nuevo, y los usuarios de service, me gustaría ser capaz de girar un nuevo server esclavo en segundo plano, una vez que está listo para servir las requestes, configurar la replicación esclavo maestro una vez más para proporcionar el mismo soporte de conmutación por error antes de.

Estoy bastante seguro de que esto se ha hecho antes, pero no puedo ver ninguna guía sobre esto, así que estoy asumiendo que debe haber alguna razón obvia que no intentaría esto, que no he pensado aún.

¿Cuáles son los escollos de tomar este enfoque para proporcionar failover automatizado como esto con MySQL?

Como un aparte, soy consciente de la replicación maestro-maestro, pero a) he visto que ir horriblemente mal, y b) parece preocupantemente demasiado complicado.

Gracias

3 Solutions collect form web for “Estrategia automatizada de conmutación por error para la replicación Mysql maestro-esclavo – ¿por qué esto no funcionaría?”

La razón failover automático no es propicio tiene que ver con el retraso de replicación. Si el esclavo se encuentra detrás y se produce la conmutación por error, es posible que esté escribiendo actualizaciones con keys que aún no existen porque aún no se han escrito las inserciones del maestro. Cuanto más retraso retraso, más esto es un problema. En mi empresa utilizamos DRBD para la conmutación por error automática ya que el server DRBD al que se realiza una conmutación por error es una copy exacta del nivel de disco del maestro original. como una política, hacemos manual para la conmutación por error para maestro / esclavo y maestro / maestro configuraciones.

Lo que quieres es un clúster de alta disponibilidad y creo que tu sugerencia parece un poco extraña.

Una buena manera de lograr esto es crear un clúster de HA de Linux y sincronizar su MySQL usando la synchronization de DRDB en el nivel de sistema de files.

En esta configuration tienes 3 cosas:

  1. La capa de postría del clúster (Linux-HA o CoroSync)
  2. El Administrador de resources de clústeres (Marcapasos)
  3. La synchronization de disco (DRDB)

En lugar de hacer un montón de código en su aplicación que utiliza una dirección IP virtual que se mueve alnetworkingedor del nodo activo actual. También usas STONITH (disparar el otro nodo en la cabeza (no hice esto)) para asegurarse de que el primer nodo está realmente muerto antes de intentar hacerse cargo de los resources.

Hay un gran material para leer en estos enlaces: http://www.linux-ha.org/wiki/Main_Page http://www.clusterlabs.org/wiki/DRBD_MySQL_HowTo http://theclusterguy.clusterlabs.org/

No descartaría la replicación maestro-maestro. De hecho, lo que usted describe es la replicación casi maestro-maestro.

Echa un vistazo a MMM (Multi-Master Replication Manager para MySQL). http://mysql-mmm.org/ Funciona en la capa mysql así que funciona mucho mejor que el clustering basado en SO.

  • mysql replication - slave parece actualizado pero los datos no están sincronizados
  • Replicar un server web de Linux
  • MM o MS replicación de EBS volumen a través de múltiples instancias de EC2
  • Cree un esclavo MySQL de otro esclavo, pero apúntelo en el maestro
  • Error de connection del esclavo al maestro con error "error de connection al maestro (1045)"
  • MySQL Replication A-> B-> C
  • CouchDB como replicación para MySQL?
  • ¿Qué database estoy sembrando en un DAG estirado?
  • Compartir / replicar EBS a través de nodos AWS
  • Replicación de SQL Server sólo para Enterprise Edition? ¿Requiere Enterprise en ambos lados? ¿Otra solución?
  • Solución para respaldo de datos de files, versionado y replicación
  • El linux y los temas del servidor de Windows, como ubuntu, centos, apache, nginx, debian y consejos de red.