PolarDB:Replicación semisincrónica basada en replicación física

Contexto

MySQL estándar ofrece una replicación semisincrónica basada en el registro binario. En este modo, el nodo primario debe esperar a que un nodo secundario confirme la recepción del registro binario generado por una transacción antes de confirmar dicha transacción. Este método de sincronización introduce latencia adicional y afecta el rendimiento de escritura del nodo primario.

PolarDB for MySQL emplea una arquitectura de replicación física para sincronizar de manera eficiente el redo log entre las zonas primaria y secundaria. Este enfoque mejora significativamente la eficiencia de la replicación semisincrónica y reduce la pérdida de rendimiento en el nodo primario. En cargas de trabajo con alta concurrencia, la degradación del rendimiento es de aproximadamente un 10 % en comparación con la replicación asincrónica.

Frente a la replicación semisincrónica basada en registros binarios de MySQL estándar, el enfoque basado en replicación física de PolarDB for MySQL ofrece una mayor eficiencia de sincronización. Durante la ejecución de una transacción, se generan registros de redo log que se transmiten a la zona secundaria en tiempo real. Por lo tanto, al momento de la confirmación, el nodo primario solo necesita esperar a que el registro de redo log correspondiente se sincronice correctamente con la zona secundaria. En cambio, el mecanismo semisincrónico tradicional genera el registro binario completo únicamente al confirmar la transacción. El nodo primario devuelve un mensaje de éxito al cliente solo después de sincronizar todo el registro binario.

Funcionamiento

La replicación semisincrónica de PolarDB for MySQL usa una arquitectura de replicación física para sincronizar datos entre las zonas primaria y secundaria mediante registros de redo log. Para una solicitud de escritura, se generan registros de redo log cuando se modifican datos en la zona primaria y luego se sincronizan a través del enlace de replicación física. El nodo primario debe esperar a que la zona secundaria acuse recibo del redo log antes de que la transacción de escritura correspondiente devuelva una respuesta exitosa.

• Tiempo máximo de espera antes de la confirmación

  Para evitar que los problemas en la zona secundaria bloqueen indefinidamente las solicitudes de escritura en la zona primaria, el kernel limita el tiempo máximo de espera antes de que se confirme una transacción de escritura. Si la zona secundaria no envía un acuse de recibo dentro de este periodo, el nodo primario confirma automáticamente la transacción.

• Mecanismo adaptativo

  En casos extremos, la zona secundaria podría no enviar acuses de recibo oportunos a la zona primaria. Esto provoca que cada solicitud de escritura espere hasta agotar el tiempo de espera antes de confirmarse, lo que genera pérdida de rendimiento. Para evitar este problema, semi-sync incluye un mecanismo adaptativo que supervisa dinámicamente la comunicación de red entre las zonas primaria y secundaria. Si los tiempos de espera se agotan con frecuencia, el sistema vuelve automáticamente a la replicación asincrónica para garantizar que las escrituras en la zona primaria no se vean afectadas. Cuando el sistema detecta que la sincronización volvió a la normalidad, habilita semi-sync automáticamente.

Aplicabilidad

Su clúster debe cumplir con los siguientes requisitos:

• **Product edition**: Enterprise Edition y Standard Edition

• **Engine version**:

  • MySQL 8.0.1:

    • Versión de revisión 8.0.1.35.1 o posterior: permite habilitar semi-sync.

    • Versión de revisión 8.0.1.1.40 o posterior: permite habilitar semi-sync y es compatible con el mecanismo adaptativo.

    • Versión de revisión 8.0.1.1.44.2 o posterior: permite habilitar semi-sync. Además, está disponible el parámetro innodb_polar_wait_slave_reply_max_time para controlar el tiempo máximo de espera predeterminado antes de confirmar una transacción de escritura. El valor predeterminado es de 500 ms.

  • MySQL 8.0.2: versión de revisión 8.0.2.2.32 y posteriores: permite habilitar semi-sync, y también es compatible con el mecanismo adaptativo y el parámetro innodb_polar_wait_slave_reply_max_time.

• Precauciones

  Nota

  El modo semi-sync basado en replicación física en PolarDB for MySQL mejora significativamente la consistencia de los datos durante las conmutaciones automáticas entre zonas. Consulte Cross-zone automatic switchover para conocer las instrucciones sobre cómo habilitar esta función.

  RPO y RTO:

  • Con la replicación asincrónica, una conmutación automática entre zonas implica pérdida de datos. El RPO es inferior a 100 ms en la mayoría de los casos y menor a 60 s en el peor escenario. Evalúe el impacto antes de usar esta función.

  • Habilitar la replicación semisincrónica reduce el rendimiento en aproximadamente un 10 %. El tiempo de espera predeterminado para la confirmación de transacciones es de 500 ms. Si se supera este tiempo, el sistema vuelve a la replicación asincrónica y deja de esperar la sincronización con la zona secundaria. Cuando no ocurre esta reversión, el RPO es 0.

  • El RTO es inferior a 30 s tanto para la replicación asincrónica como para la semisincrónica.

  Pruebas de rendimiento

  Nota

  Los resultados de las pruebas de este tema reflejan el rendimiento de la versión evaluada y podrían diferir del rendimiento de la versión más reciente.

  Método de prueba: esta prueba compara el rendimiento en consultas por segundo (QPS) de clústeres con especificaciones idénticas en tres modos: PolarDB for MySQL con replicación asincrónica, PolarDB for MySQL con semi-sync y MySQL estándar con semi-sync.

  Herramienta de prueba: Sysbench (oltp_write_only).

  Especificaciones de la prueba: 16 núcleos y 64 GB.

  Versión evaluada: PolarDB for MySQL 8.0.1 con versión de revisión 8.0.1.35.1. El rendimiento puede variar ligeramente respecto a la versión más reciente.

  Volumen de datos: 10 tablas, con 10 millones de filas por tabla.

  

  Los resultados muestran que, en escenarios de alta concurrencia, habilitar la replicación semisincrónica reduce el rendimiento en aproximadamente un 10 %. Bajo cualquier nivel de concurrencia, el rendimiento de la replicación semisincrónica basada en redo log en PolarDB for MySQL es superior al de la replicación semisincrónica basada en registros binarios en MySQL.

  Preguntas frecuentes

  P1: ¿Por qué el rendimiento se degrada más de un 10 % después de habilitar semi-sync?

  R1: En escenarios de alta concurrencia, la mejor degradación de rendimiento posible es de aproximadamente un 10 %. Esto se debe a que los registros de redo log se procesan en lotes, lo que reduce eficazmente la sobrecarga por latencia de red. En escenarios de baja concurrencia, la mejora de rendimiento derivada del procesamiento por lotes es menos significativa, lo que puede provocar una degradación más severa. Con un solo hilo de escritura, las operaciones de E/S de redo no se pueden agrupar en lotes. La latencia adicional de ida y vuelta en la red que añade la replicación semisincrónica reduce significativamente el rendimiento.

  P2: ¿Por qué no aparece el parámetro innodb_polar_wait_slave_reply_max_time en la consola? ¿Cómo lo ajusto a un valor adecuado?

  R2: Solo es posible modificar este parámetro en clústeres de PolarDB for MySQL Enterprise Edition con versión principal 8.0.1 y versión de revisión 8.0.1.1.44.2 o posterior. Si no encuentra el parámetro en la consola, compruebe primero que la versión de su clúster cumple con los requisitos. De lo contrario, ejecute una version upgrade.

  En la mayoría de los casos no es necesario modificar este parámetro. El valor predeterminado es de 500 ms. Si tiene requisitos específicos, como garantizar que una transacción espere la sincronización con la zona secundaria antes de confirmarse, aumente este valor. No obstante, el valor predeterminado de 500 ms es suficiente para la mayoría de los escenarios. Si desea limitar el tiempo de espera de la transacción, reduzca el valor del parámetro. Tenga en cuenta que establecer un valor muy pequeño, como 0 o 1 ms, puede provocar que el modo semi-sync vuelva a la replicación asincrónica. Esto ocurre porque la latencia de red entre zonas de disponibilidad suele ser inferior a 1 ms, y la replicación semisincrónica requiere como mínimo un viaje de ida y vuelta por la red. Por lo tanto, considere la latencia de red de su entorno al modificar este parámetro.

  P3: ¿Cuándo entra en vigor el mecanismo adaptativo de semi-sync? ¿Es posible habilitar semi-sync y deshabilitar el mecanismo adaptativo?

  R3: Actualmente, al habilitar semi-sync, el mecanismo adaptativo también se habilita de forma predeterminada. Este mecanismo supervisa dinámicamente el estado de sincronización entre las zonas primaria y secundaria, y aplica ajustes en tiempo real. No es posible deshabilitar el mecanismo adaptativo de forma independiente. Si desea que la función semi-sync permanezca activa, establezca innodb_polar_wait_slave_reply_max_time en un valor mayor. El mecanismo adaptativo utiliza este parámetro para detectar los tiempos de espera agotados.

  P4: El RPO es 0 cuando semi-sync no revierte su estado. ¿Esta "reversión" es lo mismo que ocurre cuando el mecanismo adaptativo deshabilita semi-sync dinámicamente?

  R4: Son conceptos distintos. "Sin reversión" significa que una transacción se confirma solo después de que su redo log se sincroniza con la zona secundaria. En este caso, se garantiza estrictamente un RPO de 0. Sin embargo, el mecanismo adaptativo supervisa a nivel de paquetes de red, no a nivel de transacciones. Cuando el mecanismo adaptativo deshabilita semi-sync dinámicamente, generalmente se debe a que varias transacciones ya se confirmaron por tiempos de espera de sincronización agotados. En otras palabras, incluso si semi-sync está habilitado y el mecanismo adaptativo no lo deshabilita, el RPO no es estrictamente 0. Algunas transacciones podrían confirmarse debido a tiempos de espera de sincronización agotados, aunque es un evento poco común. Por lo tanto, la función semi-sync garantiza que el RPO sea cercano a 0.