En la Parte I, presentamos un marco de trabajo de alta disponibilidad (HA) para el hospedaje de MySQL y discutimos varios componentes y su funcionalidad. Ahora, en la Parte II, analizaremos los detalles de la replicación semisincrónica de MySQL y los ajustes de configuración relacionados que nos ayudan a garantizar la redundancia y la coherencia de los datos en nuestra configuración de alta disponibilidad. Asegúrese de volver a consultar la Parte III, donde revisaremos varios escenarios de falla que podrían surgir y la forma en que el marco responde y se recupera de estas condiciones.
¿Qué es la replicación semisincrónica de MySQL?
En pocas palabras, en una configuración de replicación semisincrónica de MySQL, el maestro envía transacciones al motor de almacenamiento solo después de recibir el reconocimiento de al menos uno de los esclavos. Los esclavos proporcionarían reconocimiento solo después de que los eventos se reciban y se copien en los registros de retransmisión y también se descarguen en el disco. Esto garantiza que para todas las transacciones comprometidas y devueltas al cliente, los datos existen en al menos 2 nodos. El término "semi" en semisíncrono (replicación) se debe al hecho de que el maestro confirma las transacciones una vez que se reciben los eventos y se descargan en el registro de retransmisión, pero no necesariamente se confirma en los archivos de datos del esclavo. Esto contrasta con la replicación completamente síncrona, donde la transacción se habría confirmado tanto en el esclavo como en el maestro antes de que la sesión regrese al cliente.
La replicación semisincrónica, que está disponible de forma nativa en MySQL, ayuda al marco HA a garantizar la consistencia y la redundancia de los datos para las transacciones confirmadas. En caso de falla del maestro, todas las transacciones comprometidas en el maestro se habrían replicado en al menos uno de los esclavos (guardado en los registros de retransmisión). Como resultado, la conmutación por error a ese esclavo no tendría pérdidas porque el esclavo está actualizado (después de que los registros de retransmisión del esclavo se hayan vaciado por completo).
Configuración relacionada con replicación y semisíncrono
Hablemos de algunas de las configuraciones clave de MySQL utilizadas para garantizar un comportamiento óptimo para una alta disponibilidad y consistencia de datos en nuestro marco.
Administración de la velocidad de ejecución de los esclavos
La primera consideración es manejar el comportamiento 'semi' de la replicación semisincrónica que solo garantiza que los datos hayan sido recibidos y enviados a los registros de retransmisión por el subproceso de E/S del esclavo, pero no necesariamente comprometido por el subproceso SQL. De forma predeterminada, el subproceso SQL en un esclavo MySQL es de un solo subproceso y no podrá seguir el ritmo del maestro que tiene varios subprocesos. El impacto obvio de esto es que, en caso de que falle el maestro, el esclavo no estará actualizado ya que su subproceso SQL todavía está procesando los eventos en el registro de retransmisión. Esto retrasará el proceso de conmutación por error ya que nuestro marco espera que el esclavo esté completamente actualizado antes de que pueda promocionarse. Esto es necesario para preservar la consistencia de los datos. Para abordar este problema, habilitamos esclavos de subprocesos múltiples con la opción slave_parallel_workers para establecer la cantidad de subprocesos SQL paralelos para procesar eventos en los registros de retransmisión.
Además, configuramos los siguientes ajustes que garantizan que el esclavo no entre en ningún estado en el que el maestro no se encontraba:
- tipo-esclavo-paralelo =LOGICAL_CLOCK
- slave_preserve_commit_order =1
Esto nos brinda una consistencia de datos más sólida. Con esta configuración, podremos obtener una mejor paralelización y velocidad en el esclavo, pero si hay demasiados subprocesos paralelos, la sobrecarga involucrada en la coordinación entre los subprocesos también aumentará y, lamentablemente, puede contrarrestar los beneficios.
Otra configuración que podemos usar para aumentar la eficiencia de la ejecución paralela en los esclavos es ajustar binlog_group_commit_sync_delay en el maestro. Al configurar esto en el maestro, las entradas del registro binario en el maestro y, por lo tanto, las entradas del registro de retransmisión en el esclavo tendrán lotes de transacciones que los subprocesos SQL pueden procesar en paralelo. Esto se explica en detalle en el blog de J-F Gagné, donde se refiere a este comportamiento como "ralentizar al maestro para acelerar al esclavo" .
Si está administrando sus implementaciones de MySQL a través de la consola ScaleGrid, tiene la capacidad de monitorear continuamente y recibir alertas en tiempo real sobre el retraso de replicación de los esclavos. También le permite ajustar dinámicamente los parámetros anteriores para garantizar que los esclavos trabajen mano a mano con el maestro, por lo tanto, minimizando el tiempo involucrado en un proceso de conmutación por error.
Explicación del marco de alta disponibilidad de MySQL - Parte IIHaga clic para twittear
Opciones importantes de replicación semisincrónica
La replicación semisincrónica de MySQL, por diseño, puede volver al modo asíncrono en función de la configuración del tiempo de espera de reconocimiento del esclavo o en función de la cantidad de esclavos con capacidad semisincrónica disponibles en cualquier momento. El modo asíncrono, por definición, no ofrece garantías de que las transacciones comprometidas se repliquen en el esclavo y, por lo tanto, una pérdida del maestro provocaría la pérdida de los datos que no se han replicado. El diseño predeterminado del marco ScaleGrid HA es para evitar volver al modo asíncrono. Revisemos las configuraciones que influyen en este comportamiento.
-
rpl_semi_sync_master_wait_for_slave_count
Esta opción se usa para configurar el número de esclavos que deben enviar un reconocimiento antes de que un maestro semisíncrono pueda confirmar la transacción. En la configuración maestro-esclavo de 3 nodos, configuramos esto en 1 para que siempre tengamos la seguridad de que los datos están disponibles en al menos un esclavo mientras evitamos cualquier impacto en el rendimiento relacionado con la espera del reconocimiento de ambos esclavos.
-
rpl_semi_sync_master_timeout
Esta opción se usa para configurar la cantidad de tiempo que un maestro semisíncrono espera el reconocimiento de un esclavo antes de volver al modo asíncrono. Establecemos esto en un valor de tiempo de espera relativamente alto para que no haya retroceso al modo asíncrono.
Dado que estamos operando con 2 esclavos y el rpl_semi_sync_master_wait_for_slave_count está establecido en 1, hemos notado que al menos uno de los esclavos reconoce dentro de un período de tiempo razonable y el maestro no cambia al modo asíncrono durante las interrupciones temporales de la red.
-
rpl_semi_sync_master_wait_no_slave
Esto controla si el maestro espera a que expire el período de tiempo de espera configurado por rpl_semi_sync_master_timeout, incluso si el recuento de esclavos cae por debajo del número de esclavos configurado por rpl_semi_sync_master_wait_for_slave_count durante el período de tiempo de espera. Mantenemos el valor predeterminado de ON para que el maestro no recurra a la replicación asíncrona.
Impacto de perder todos los esclavos semisincrónicos
Como vimos anteriormente, nuestro marco evita que el maestro cambie a la replicación asíncrona si todos los esclavos se caen o se vuelven inaccesibles desde el maestro. El impacto directo de esto es que las escrituras se estancan en el maestro, lo que afecta la disponibilidad del servicio. Esto es esencialmente como lo describe el teorema CAP sobre las limitaciones de cualquier sistema distribuido. El teorema establece que, en presencia de una partición de red, tendremos que elegir disponibilidad o consistencia, pero no ambas. La partición de red, en este caso, se puede considerar como esclavos de MySQL desconectados del maestro porque están inactivos o no se pueden alcanzar.
Nuestro objetivo de consistencia es garantizar que para todas las transacciones comprometidas, los datos estén disponibles en al menos 2 nodos. Como resultado, en tales casos, el marco ScaleGrid HA favorece la consistencia sobre la disponibilidad. No se aceptarán más escrituras de los clientes, aunque el maestro MySQL seguirá atendiendo las solicitudes de lectura. Esta es una decisión de diseño consciente que hemos tomado como el comportamiento predeterminado que, por supuesto, es configurable en función de los requisitos de la aplicación.
Asegúrese de suscribirse al blog de ScaleGrid para no perderse la Parte III, donde analizaremos más escenarios de fallas y capacidades de recuperación del marco MySQL HA . ¡¡Estad atentos!!
