Estrategia de recuperación para la replicación Master-Master

He implementado una solución HA para mysql basada en la replicación maestro-maestro. Hay un mecanismo en la parte frontal que garantiza que solo se leerá / escribirá un db en un momento dado (es decir, solo usamos replicación para HA).

He confirmado que la replicación funciona como se esperaba, pero me pregunto sobre el escenario de falla y la recuperación. En particular, me preocupa lo que sucede cuando un maestro falla en un estado irrecuperable y necesita ser recreado del otro maestro:

• Como el otro maestro está activo y es muy probable que lo use, no puedo bloquearlo y crear volcados mysqldump(nuestras bases de datos son moderadamente grandes y mysqldumppueden tardar horas después de algunos meses de uso).
• Incluso suponiendo que tengo un volcado, es crucial que la posición del binlog como se muestra en SHOW MASTER STATUS corresponda al volcado que se realiza después de que la base de datos ha sido bloqueada.

La solución simple al primer problema es usar una tercera base de datos que actúe como una copia de seguridad, desde la cual puedo hacer el mysqldump. Pero entonces, ¿cómo me aseguro de que el maestro recreado pueda iniciar la replicación desde el maestro en ejecución de manera consistente?

Hay dos enfoques básicos para este problema que conozco. Primero, si está ejecutando InnoDB en lugar de Myisam, puede hacer la copia de seguridad en una transacción (--single-transaction --lock-tables = FALSE), que se combina con --flush-logs (no es obligatorio pero sí agradable) y --master-data le dará una copia de seguridad consistente con información de posición de replicación. Los registros de vaciado restablecerán los registros antes de que se cree el volcado, lo que significa que la posición siempre será 106, y --master-data colocará el nombre y la posición del archivo de registro directamente en el archivo de volcado. Por supuesto, debe ejecutar esto en el maestro para que --master-data funcione.

La segunda forma, que mencionó, es utilizar un tercer host para crear las copias de seguridad. En este caso, debe detener la replicación, asegúrese de que la base de datos sea de solo lectura (aunque en realidad, todas sus réplicas deben leerse solo ya que esto no afecta las escrituras de la replicación) y luego cree su copia de seguridad Y registre la posición de replicación. No puede usar --master-data en este caso. En cambio, podrías hacer algo como esto:

echo 'stop slave' | mysql {options)
mysqldump {your options} > DB.sql
echo 'show slave status\G' > DB.replication
echo 'start slave' | mysql {options)

Si alguna vez necesita restaurar desde esta copia de seguridad, ejecute la restauración y luego configure la replicación donde los dos parámetros master_log_file y master_log_pos provienen del archivo DB.replication:

master_log_file = value of Master_Log_File
master_log_pos = value of Exec_Master_Log_Pos

Nota: puede Y DEBE probar esto desde otra réplica.

Nota adicional: si tiene un grupo de réplicas (por ejemplo, si ha separado las lecturas de las escrituras para una aplicación web) es posible que las réplicas no estén sincronizadas con el nuevo maestro; Esto puede suceder si la conmutación por error se produce durante un período de E / S de escritura intensiva, ya que las réplicas se transmiten de forma asincrónica y no hay garantía de que su modo de espera esté en la misma posición que las otras réplicas cuando realiza la conmutación por error. Sin embargo, esto no me ha pasado todavía ...