¿Cómo se vuelve a sincronizar el Master MySQL DB con los cambios de Slave DB si el Master se desconecta?

MySQL Server 1 se ejecuta como maestro.
MySQL Server 2 se ejecuta como esclavo.

Con ambos DB en línea, están en "sincronización perfecta". Si Slave se desconecta, no hay problema si Master aún está en línea; volverán a sincronizarse una vez que el Esclavo vuelva a estar en línea.

Además de la configuración del servidor, redirigí la conexión (con el código JSP) para Slave DB si el maestro se desconecta (lo probé, por supuesto, con /etc/init.d/mysqld stop).

Cuando el Maestro vuelve a estar en línea, ¿hay algún método automático para sincronizar las actualizaciones del Maestro con el Esclavo?

Una buena forma de lograr algo de esa naturaleza es configurar la replicación maestro-maestro o la replicación circular. Esto no debe confundirse con MultiMaster Replciation.

Configurar la Replicación circular es realmente muy fácil si ha configurado la Replicación maestro-esclavo. Esto es lo que debe hacer para configurarlo.

Para este ejemplo, asumiremos que la replicación maestro-esclavo está activa, pero experimentará un poco de tiempo de inactividad (1-2 minutos):

Paso 1) Agregue esta línea a /etc/my.cnf en el Master.

log-slave-updates

Paso 2) Agregue estas líneas a /etc/my.cnf en Slave:

log-bin = mysql-bin (o tiene lo que el maestro tiene para esto) log-slave-updates

ADVERTENCIA: ¡Aquí está el breve momento de inactividad!

Paso 3) En Slave, reinicie mysql de servicio

Esto activará registros binarios en el esclavo.

Paso 4) En Master, service mysql stop

Paso 5) Use rsync para copiar la carpeta / var / lib / mysql del Esclavo al Maestro.

ADVERTENCIA: ¡Aquí está el momento más largo de tiempo de inactividad!

Paso 6) En Slave, service mysql stop

Paso 7) En Slave, encuentre el último registro binario

Paso 8) En Slave, averigüe el tamaño de archivo del último registro binario

Paso 9) Use rsync para copiar la carpeta / var / lib / mysql del Slave al Master. Esta debería ser una copia más rápida.

Paso 10) En el Maestro, edite la
Línea 2 de master.info con el último registro binario del Esclavo.
Línea 3 de master.info con el tamaño de archivo del último registro binario de Slave.
Línea 4 de master.info con la IP del esclavo.
La línea 5 es el ID de usuario del usuario de replicación (NO TOCAR) La
línea 6 es la contraseña del usuario de replicación (NO TOCAR)

Paso 11) Elimine todos los registros binarios y el archivo de índice de registro binario del maestro.

Paso 12) En el Esclavo, inicie el servicio mysql, espere 15 segundos

Paso 13) En el maestro, inicie el servicio mysql

Paso 14) En el maestro, ejecute STOP SLAVE; MOSTRAR ESTADO MAESTRO;

Paso 15) En el Esclavo, ejecute CHANGE MASTER TO MASTER_HOST = 'IP of Slave', MASTER_USER = 'userid of replication user from Step10', MASTER_PASSWORD = 'password of replication user from Step10', MASTER_LOG_FILE = 'log binary from Step14', MASTER_LOG_POS = LogPos del paso 14.

Paso 16) En el esclavo, ejecute START SLAVE;

Paso 17) En el maestro, ejecute START SLAVE;

Realicé pasos similares a este para otra pregunta de StackExchange que respondí .

Darle una oportunidad !!!

No con la replicación asincrónica, que es lo que ofrece MySQL. Acaba de llegar al clavo proverbial de por qué la replicación MySQL 'lista para usar' (pre 5.5) no es una solución de alta disponibilidad en sí misma. Las cosas mejoran ligeramente con 5.5 con replicación semisíncrona (http://dev.mysql.com/doc/refman/5.5/en/replication-semisync.html) pero a costa de un tiempo de transacción más lento mientras el maestro espera el Ack de esclavo.

Si aceptar la posibilidad de pérdida de datos cuando el maestro deja de funcionar no es una opción, diría que se necesita una configuración más sofisticada que el simple maestro / esclavo.

La replicación de maestro a maestro ha sido considerada más problemática que beneficios por muchas personas famosas de MySQL (incluso MySQL AB ya no la recomienda como una solución de alta disponibilidad). Entonces, creo que usar la configuración DRBD para mantener sincronizados el maestro activo y el esclavo pasivo usando copias a nivel de bloque es lo que realmente necesita aquí.

En mi humilde opinión, en primer lugar, en una configuración no multimaestro (maestro / esclavo), su esclavo nunca debe tomar escrituras. El my.cnf esclavo debe configurarse y el servidor debe comenzar con:

# Flag to not take writes from network
read-only

A continuación, para solucionar el problema de un maestro fuera de sincronización con un esclavo grabable que toma escrituras accidentalmente, debe diferenciar los datos en ambos hosts. Si no hay una colisión de claves, debe promover su antiguo host esclavo a maestro y volver a crear una imagen de su antiguo maestro como un host esclavo que se replica del nuevo maestro. (podría haber / probablemente haya problemas de datos aquí)

Finalmente, si este escenario de interrupción / tiempo de inactividad es incluso una posibilidad en el futuro , tómese el tiempo para configurar ambos hosts como multimaestro (log-bin, server-id, offsets, etc.). Esto lo ayudará a mitigar las interrupciones y los tiempos de inactividad hasta cierto punto.

Si tiene que ejecutar maestro / esclavo , al menos obtenga algunos puntos de bonificación por separar las conexiones de lectura y escritura del usuario en su ACL y sus aplicaciones.