ApsaraDB RDS:Usar Binlog Parallel Flush

Requisitos previos

• Su instancia RDS ejecuta MySQL 8.0.

• Su instancia RDS ejecuta una versión secundaria del motor 20230930 o posterior.

  Nota

  Para consultar la versión secundaria del motor de su instancia RDS, inicie sesión en la consola de ApsaraDB RDS y vaya a la página Basic Information. En la sección Configuration Information, compruebe si se muestra el botón Upgrade Minor Engine Version. Si se muestra, haga clic en él; después, consulte y actualice la versión secundaria del motor de su instancia RDS. Si no se muestra, su instancia RDS ejecuta la versión secundaria del motor más reciente. Para obtener más información, consulte Upgrade the minor engine version.

• El parámetro sync_binlog de su instancia RDS no está establecido en 1.

Información de contexto

En MySQL, el sistema escribe datos en los registros binarios cada vez que se confirma una transacción. Las escrituras se realizan de forma secuencial. El sistema escribe en los registros binarios los datos de una transacción tras otra.

El proceso de escritura consume mucho tiempo. Antes de escribir datos en los registros binarios, el sistema debe analizar todos los eventos almacenados en la caché del registro binario, asignar valores a los parámetros Checksum y log_pos, y generar eventos de identificador global de transacciones (GTID). Este proceso de escritura supone un cuello de botella importante para el rendimiento de escritura de la instancia RDS. Para resolver este cuello de botella, AliSQL optimiza la función Binlog Parallel Flush.

Detalles de la optimización

Búfer de registro binario

AliSQL introduce un búfer de registro binario para implementar la optimización. Una vez asignados varios hilos, el sistema puede escribir eventos de registro binario en el búfer de registro binario en paralelo. Luego, los hilos de backend escriben los datos del búfer de registro binario en archivos de registro binario. De esta manera, el sistema puede ejecutar en paralelo las operaciones que deben completarse en secuencia. Estas operaciones incluyen asignar valores a los parámetros Checksum y log_pos, y generar eventos GTID. Esto mejora significativamente el rendimiento de escritura cuando se escriben eventos en archivos de registro binario.

Confirmación en grupo

En MySQL, el sistema escribe datos en los archivos de registro binario y en los archivos de registro de rehacer de distintos grupos de transacciones durante la confirmación de la transacción. Esto ayuda a fusionar las operaciones de E/S en la mayor medida posible y a mejorar el rendimiento. Después de la optimización, se conserva el concepto de confirmación en grupo. A continuación, la imagen muestra la función Binlog Parallel Flush con confirmación en grupo.

Después de la optimización, el sistema asigna GTID y búferes de registro binario para las transacciones, uno tras otro. Luego, el sistema escribe los eventos de registro binario del grupo de transacciones en los búferes de registro binario. Una vez que se almacenan los archivos de registro de rehacer y el hilo de backend escribe los datos de los búferes de registro binario en archivos de registro binario, el grupo de transacciones puede confirmarse.

Persistencia de los registros binarios

Después de la optimización, un hilo de backend persiste los archivos de registro binario a intervalos regulares. De forma predeterminada, un archivo de registro binario se persiste una vez por segundo.

Descripción del parámetro

loose_binlog_parallel_flush

Este parámetro especifica si se debe habilitar la función Binlog Parallel Flush. Este parámetro es una variable global del sistema. Valores válidos: on y off. Si modifica el valor de este parámetro, el cambio surte efecto inmediatamente. No es necesario que reinicie su instancia RDS.

Efecto de la optimización

Entorno de prueba

La tabla que aparece a continuación describe el efecto de la optimización de esta función en instancias de ApsaraDB RDS for MySQL que utilizan distintas especificaciones.

Configuración de parámetros

La instancia RDS de la prueba usa una plantilla de parámetros de alto rendimiento. En la plantilla, se usa la configuración de parámetros relacionada con el rendimiento que se indica a continuación: sync_binlog = 1000 y innodB_flush_log_at_trx_commit = 2.

Script de prueba

Para la prueba de rendimiento se usa el script oltp_update_non_index de Sysbench. Los datos de prueba contienen 100 tablas y cada tabla contiene 100,000 filas.

Resultados de la prueba

A continuación, la imagen muestra los resultados de la prueba. En comparación con MySQL Normal Flush nativo, Binlog Parallel Flush mejora significativamente el rendimiento de escritura de una instancia RDS. La mejora máxima puede ser de entre un 10 % y un 30 %.