En una configuración maestro-esclavo de MySQL 5.7 que usa la configuración de replicación semisincrónica predeterminada para rpl_semi_sync_master_wait_point , un bloqueo del maestro y una conmutación por error al esclavo se considera sin pérdidas. Sin embargo, cuando el maestro bloqueado regresa, es posible que tenga transacciones que no están presentes en el maestro actual (que anteriormente era un esclavo). Este comportamiento puede resultar desconcertante, dado que se supone que la replicación semisincrónica no tiene pérdidas, pero en realidad es un comportamiento esperado en MySQL. Por qué ocurre exactamente esto se explica con todo detalle en la entrada del blog de Jean-François Gagné (JF).
Dado tal escenario, la documentación de MySQL recomienda que el maestro bloqueado se descarte y no se reinicie. Sin embargo, descartar un servidor como este es costoso e ineficiente. En esta publicación de blog, explicaremos un enfoque para detectar y corregir transacciones en el servidor maestro de MySQL bloqueado en una configuración de replicación semisincrónica y cómo volver a convertirlo en esclavo en su configuración maestro-esclavo.
¿Por qué es importante detectar transacciones adicionales en el maestro recuperado?
Las transacciones adicionales en el maestro recuperado pueden manifestarse de dos maneras:
1. La replicación de MySQL falla cuando el maestro recuperado se vuelve a convertir en esclavo
Por lo general, esto sucede cuando tiene una clave principal de incremento automático. Cuando el nuevo maestro de MySQL inserta una fila en dicha tabla, la replicación fallará porque la clave ya existe en el esclavo.
Otro escenario es cuando su aplicación vuelve a intentar la transacción que falló durante el bloqueo maestro. En el maestro MySQL recuperado (que ahora es un esclavo), esta transacción realmente existiría y, nuevamente, daría como resultado un error de replicación.
Por lo general, el error de replicación de MySQL se vería así:
| [ERROR] SQL esclavo para el canal '':Worker 5 falló al ejecutar la transacción 'fd1ba8f0-cbee-11e8- b27f-000d3a0df42d:5938858' en el registro maestro mysql-bin.000030, end_log_pos 10262184; Error 'Entrada duplicada '5018' para la clave 'PRIMARIA' en la consulta. Base de datos predeterminada:'prueba'. Consulta:'insertar en valores de prueba (5018,2019, 'elemento 100')', Error_code:1062 |
2. Inconsistencia silenciosa en los datos entre el nuevo MySQL maestro y esclavo (maestro recuperado)
En los casos en que la aplicación no vuelve a intentar la transacción fallida y no hay colisiones de claves principales en el futuro, es posible que no se produzca un error de replicación. Como resultado, la inconsistencia de los datos puede pasar desapercibida.
En los dos casos anteriores, la alta disponibilidad o la integridad de los datos de su configuración de MySQL se ven afectadas, por lo que es tan importante detectar esta condición lo antes posible.
Cómo detectar transacciones adicionales en el maestro MySQL recuperado
Podemos detectar si hay transacciones adicionales en el maestro recuperado usando la función MySQL GTID (identificador de transacción global):
GTID_SUBSET(conjunto1 ,conjunto2 ):dados dos conjuntos de ID de transacciones globales set1 y conjunto2 , devuelve verdadero si todos los GTID en set1 también están en set2 . De lo contrario, devuelve falso.
Usemos un ejemplo para entender esto.
- GTID establecido en el maestro recuperado cuyo UUID es:'54a63bc3-d01d-11e7-bf52-000d3af93e52 es:
- '54a63bc3-d01d-11e7-bf52-000d3af93e52:1-9690,57956099-d01d-11e7-80bc-000d3af97c09:1-870’
Ahora, si llamamos a la función GTID_SUBSET como GTID_SUBSET(conjunto GTID del maestro recuperado, conjunto GTID del nuevo maestro) , el valor devuelto será verdadero, solo si el maestro recuperado no tiene transacciones adicionales. En nuestro ejemplo anterior, dado que el maestro recuperado tiene transacciones adicionales de 9691 a 9700, el resultado de la consulta anterior es falso.
Volver a esclavizar un servidor maestro #MySQL colapsado en la configuración de replicación semisincrónicaHaga clic para twittearCómo volver a convertir en esclavo el maestro MySQL recuperado que tiene transacciones adicionales
Según el paso anterior, es posible saber si el maestro recuperado tiene transacciones adicionales y cuáles son estas transacciones utilizando la función GTID:GTID_SUBTRACT(GTID conjunto de maestro recuperado, conjunto de GTID del nuevo maestro).
También es posible extraer estas transacciones adicionales de los registros binarios y guardarlas. Puede ser útil para su equipo de negocios revisar estas transacciones más tarde para asegurarse de que no estamos perdiendo inadvertidamente ninguna información comercial importante, aunque no haya sido confirmada. Una vez hecho esto, necesitamos una forma de deshacernos de estas transacciones adicionales para que el maestro recuperado pueda volver a ser esclavo sin problemas.
Una de las formas más sencillas de hacer esto es tomar una instantánea de respaldo en el maestro actual y restaurar los datos en su esclavo actual. Recuerde que debe conservar el UUID de este servidor como antes. Una vez que haya restaurado los datos, el servidor puede volver a ser esclavo y comenzará la replicación desde el punto de la instantánea restaurada. ¡Pronto tendrás un esclavo sano funcionando de nuevo!
Los pasos anteriores son muy tediosos si tiene que realizarlos manualmente, pero el servicio de alojamiento MySQL completamente administrado de ScaleGrid puede automatizar todo el proceso sin necesidad de intervención alguna. Así es como funciona:
Si su maestro actual falla, ScaleGrid automatiza el proceso de conmutación por error y promueve un esclavo adecuado como el nuevo maestro. Luego se recupera el maestro anterior y detectamos automáticamente si hay transacciones adicionales en él. Si se encuentra alguno, la implementación de MySQL se pone en un estado degradado y utilizamos herramientas automatizadas para extraer y guardar las transacciones adicionales para su revisión. ¡Nuestro equipo de soporte puede restaurar el antiguo maestro a un buen estado y volver a convertirlo en esclavo en su configuración maestro-esclavo para que tenga una implementación saludable!
¿Quieres probarlo? Comience una prueba gratuita de 30 días para explorar todas las capacidades de administración de bases de datos MySQL en ScaleGrid.
