En esta serie de blogs de tres partes, presentamos un marco de alta disponibilidad (HA) para alojamiento MySQL en la Parte I y discutimos los detalles de la replicación semisincrónica de MySQL en la Parte II. Ahora, en la Parte III, revisamos cómo el marco maneja algunos de los escenarios de falla importantes de MySQL y se recupera para garantizar una alta disponibilidad.
Escenarios de fallas de MySQL
Escenario 1:MySQL maestro deja de funcionar
- El marco Corosync y Pacemaker detecta que el MySQL maestro ya no está disponible. Pacemaker degrada el recurso maestro e intenta recuperarlo reiniciando el servicio MySQL, si es posible.
- En este punto, debido a la naturaleza semisincrónica de la replicación, al menos uno de los esclavos ha recibido todas las transacciones realizadas en el maestro.
- Pacemaker espera hasta que todas las transacciones recibidas se apliquen a los esclavos y permite que los esclavos informen sus puntajes de promoción. El cálculo de la puntuación se realiza de tal manera que la puntuación es '0' si un esclavo está completamente sincronizado con el maestro, y es un número negativo de lo contrario.
- Pacemaker elige el esclavo que ha informado la puntuación 0 y promueve ese esclavo que ahora asume el rol de maestro MySQL en el que se permiten escrituras.
- Después de la promoción de esclavos, el agente de recursos activa un módulo de redirección de DNS. El módulo actualiza la entrada DNS del proxy con la dirección IP del nuevo maestro, lo que facilita que todas las escrituras de la aplicación se redirijan al nuevo maestro.
- Pacemaker también configura los esclavos disponibles para comenzar a replicar desde este nuevo maestro.
Por lo tanto, cada vez que un MySQL maestro deja de funcionar (ya sea debido a un bloqueo de MySQL, un bloqueo del sistema operativo, un reinicio del sistema, etc.), nuestro marco HA lo detecta y promueve un esclavo adecuado para asumir el papel de maestro. Esto garantiza que el sistema siga estando disponible para las aplicaciones.
#Explicación del marco de alta disponibilidad de MySQL - Parte III:Escenarios de fallaHaga clic para twittear
Escenario 2:MySQL esclavo se cae
- El marco Corosync y Pacemaker detecta que MySQL esclavo ya no está disponible.
- Pacemaker intenta recuperar el recurso intentando reiniciar MySQL en el nodo. Si aparece, se vuelve a agregar al maestro actual como esclavo y la replicación continúa.
- Si falla la recuperación, Pacemaker informa que ese recurso está inactivo, según las alertas o notificaciones que se pueden generar. Si es necesario, el equipo de soporte de ScaleGrid se encargará de la recuperación de este nodo.
- En este caso, no hay impacto en la disponibilidad de los servicios de MySQL.
Escenario 3:partición de red:la conectividad de red se interrumpe entre los nodos maestro y esclavo
Este es un problema clásico en cualquier sistema distribuido donde cada nodo piensa que los otros nodos están inactivos, mientras que en realidad, solo se interrumpe la comunicación de red entre los nodos. Este escenario se conoce más comúnmente como escenario de cerebro dividido y, si no se maneja correctamente, puede llevar a que más de un nodo afirme ser un MySQL maestro, lo que a su vez genera inconsistencias y corrupción de datos.
Usemos un ejemplo para revisar cómo nuestro marco trata los escenarios de cerebro dividido en el clúster. Suponemos que, debido a problemas de red, el clúster se dividió en dos grupos:maestro en un grupo y 2 esclavos en el otro grupo, y lo denotaremos como [(M), (S1,S2)].
- Corosync detecta que el nodo maestro no puede comunicarse con los nodos esclavos y los nodos esclavos pueden comunicarse entre sí, pero no con el maestro .
- El nodo maestro no podrá realizar ninguna transacción ya que la replicación semisincrónica espera el reconocimiento de al menos uno de los esclavos antes de que el maestro pueda confirmar. Al mismo tiempo, Pacemaker cierra MySQL en el nodo maestro debido a la falta de quórum según la configuración de Pacemaker "no-quorum-policy =stop". Quórum aquí significa la mayoría de los nodos, o dos de tres en una configuración de clúster de 3 nodos. Dado que solo hay un nodo maestro ejecutándose en esta partición del clúster, se activa la configuración de política sin quórum, lo que lleva al apagado del maestro MySQL.
- Ahora, Pacemaker en la partición [(S1), (S2)] detecta que no hay ningún maestro disponible en el clúster e inicia un proceso de promoción. Suponiendo que S1 esté actualizado con el maestro (como lo garantiza la replicación semisincrónica), se promociona como el nuevo maestro.
- El tráfico de la aplicación se redirigirá a este nuevo nodo maestro de MySQL y el esclavo S2 comenzará a replicarse desde el nuevo maestro.
Por lo tanto, vemos que el marco MySQL HA maneja los escenarios de cerebro dividido de manera efectiva, asegurando tanto la consistencia como la disponibilidad de los datos en caso de que la conectividad de la red se interrumpa entre los nodos maestro y esclavo.
Esto concluye nuestra serie de blogs de tres partes sobre el marco de trabajo de alta disponibilidad (HA) de MySQL que utiliza la replicación semisíncrona y la pila Corosync más Pacemaker. En ScaleGrid, ofrecemos alojamiento de alta disponibilidad para MySQL en AWS y MySQL en Azure que se implementa según los conceptos explicados en esta serie de blogs. Visite ScaleGrid Console para obtener una prueba gratuita de nuestras soluciones.
