ApsaraDB RDS:Binlog in Redo

Requisitos previos

• Versión de la base de datos:

  • MySQL 8.4

  • MySQL 8.0: la versión secundaria del motor debe ser 20200430 o posterior. Para actualizar la versión secundaria del motor de su instancia, consulte Upgrade the minor engine version.

• Establezca el parámetro sync_binlog de la instancia en 1 y el parámetro binlog_order_commits en OFF. Para obtener más información, consulte Set instance parameters.

• Configure el modo de replicación de datos de la instancia como replicación asíncrona. Para obtener más información, consulte Query and modify the data replication mode.

Contexto

En escenarios críticos de MySQL, es obligatorio vaciar de forma síncrona el registro binario y el redo log en el disco cuando se confirma una transacción. De esta manera se garantiza la seguridad de los datos. Por lo tanto, los dos parámetros siguientes deben configurarse en 1:

sync_binlog = 1;
innodb_flush_log_at_trx_commit = 1;

En MySQL estándar, cada confirmación de transacción requiere dos operaciones de E/S síncronas en disco: una para el registro binario y otra para el redo log. Este requisito disminuye la eficiencia de las confirmaciones, un impacto que resulta más evidente en discos en la nube.

Para mejorar la eficiencia en la confirmación de transacciones, AliSQL introdujo la función Binlog in Redo. Esta función se habilita al configurar el parámetro persist_binlog_to_redo=ON y está deshabilitada de forma predeterminada. Cuando se confirma una transacción, la función combina el contenido del registro binario con el redo log y los escribe de manera conjunta. Solo se necesita una operación de E/S síncrona para conservar el redo log, lo que también vacía los datos del registro binario en el disco. Este diseño elimina las dos operaciones de E/S independientes que exige MySQL estándar para el registro binario y el redo log. Como resultado, se reduce significativamente la latencia y aumenta el rendimiento.

Además, Binlog in Redo utiliza procesamiento por lotes y un mecanismo de confirmación en grupo para mitigar la contención de bloqueos generada por la asignación de GTID en escenarios de alta concurrencia. Este enfoque reduce los conflictos de bloqueo y garantiza un alto rendimiento.

Un hilo en segundo plano escribe de forma asíncrona el archivo de registro binario y anexa datos por lotes de manera periódica. Así se evita la presión sobre el sistema de archivos que generan las llamadas a fsync en tiempo real, lo cual mejora la eficiencia general de E/S. Incluso si la base de datos se reinicia de forma inesperada, el sistema restaura automáticamente la integridad del archivo de registro binario. Para ello, reproduce los datos del registro binario almacenados dentro del redo log y garantiza la consistencia de los datos.

La función Binlog in Redo no modifica el formato del registro binario. Por lo tanto, la replicación y las herramientas de terceros basadas en este registro no se ven afectadas.

Notas

Después de habilitar la función Binlog in Redo, utilice la herramienta XtraBackup proporcionada por RDS si necesita restaurar una instancia de disco local de alto rendimiento en una base de datos autogestionada mediante un archivo de copia de seguridad física. Para instalar la herramienta XtraBackup, consulte Tool preparation.

Parámetros

• persist_binlog_to_redo

  Habilita o deshabilita la función Binlog in Redo. Se trata de una variable global del sistema. Valores válidos: on u off. Los cambios en este parámetro surten efecto de inmediato sin necesidad de reiniciar la instancia.

  Nota

  Para habilitar esta función, además de establecer persist_binlog_to_redo en on, debe configurar binlog_order_commits en off y definir el modo de replicación de datos de la instancia como replicación asíncrona.

  • Para obtener más información sobre cómo configurar los parámetros de la instancia, consulte Set instance parameters.

  • Para conocer más detalles sobre cómo configurar el modo de replicación de datos, consulte Query and modify the data replication mode.

  Si el parámetro sync_binlog de su instancia no está configurado en 1, la función Binlog in Redo no se habilitará aunque configure los parámetros anteriores. En este caso, se recomienda utilizar la función Binlog Parallel Flush para optimizar el rendimiento de su instancia.

• sync_binlog_interval

  Intervalo en el que los registros binarios se conservan de forma asíncrona. Es una variable global del sistema y solo surte efecto cuando persist_binlog_to_redo = on. El valor predeterminado es 50 y la unidad es milisegundos (ms). En la mayoría de los casos, el valor predeterminado es suficiente. Los cambios en este parámetro surten efecto de inmediato sin necesidad de reiniciar la instancia.

Pruebas de rendimiento

• Entorno de prueba

  • Servidor de aplicaciones: una instancia de ECS de Alibaba Cloud

  • Especificaciones de la instancia RDS: 32 núcleos, 128 GB de memoria, disco en la nube ESSD

  • Tipo de instancia: High-availability Edition (modo de replicación de datos: replicación asíncrona)

• Casos de prueba

  A continuación se muestran los casos de prueba integrados de Sysbench que se utilizaron:

  • oltp_update_non_index

  • oltp_write_only

• Resultados de la prueba

  • oltp_update_non_index

    Al habilitar Binlog in Redo, el TPS aumenta de manera significativa en escenarios de baja concurrencia y de forma notable en escenarios de alta concurrencia, con una menor latencia.

    

  • oltp_write_only

    Una vez habilitado Binlog in Redo, el TPS aumenta considerablemente tanto en escenarios de baja como de alta concurrencia, con una menor latencia.

    

Conclusiones

• El caso de prueba oltp_update_non_index contiene únicamente transacciones de una sola instrucción, por lo que realiza confirmaciones con mayor frecuencia. En cambio, oltp_write_only incluye transacciones de múltiples instrucciones (dos instrucciones UPDATE, una instrucción DELETE y una instrucción INSERT), de modo que confirma con menor frecuencia. En consecuencia, la mejora de rendimiento para oltp_update_non_index es más significativa que para oltp_write_only.

• Con menos de 64 conexiones simultáneas, la función Binlog in Redo mejora notablemente el rendimiento y reduce la latencia. Esto la hace eficaz para la mayoría de las cargas de trabajo en producción.

• Cuando hay más de 256 conexiones simultáneas, la función Binlog in Redo ofrece un rendimiento máximo superior y una latencia más baja. Gracias a esto, gestiona mejor los picos repentinos de tráfico.