Optimización de la latencia de replicación en transacciones grandes - ApsaraDB RDS

ApsaraDB RDS for MySQL utiliza replicación lógica. Cuando una transacción se ejecuta en la instancia principal, sus eventos binlog se envían a una réplica para que esta los aplique y garantice la consistencia de los datos. Sin embargo, con esta arquitectura, las transacciones grandes de larga duración generan una latencia de replicación significativa en la réplica. Para resolver este problema, ApsaraDB RDS for MySQL incorpora una función de aplicación en tiempo real para transacciones grandes. Esta función permite que la réplica comience a ejecutar una transacción grande mientras esta aún se procesa en la instancia principal. Al ejecutar la transacción de forma simultánea en ambas instancias, se elimina casi por completo la latencia de replicación resultante y se garantiza la alta disponibilidad de su instancia.

Funcionamiento

imagen

Latencia de replicación en transacciones grandes (diagrama izquierdo): en MySQL, la réplica comienza a aplicar una transacción grande únicamente después de que esta se confirma en la instancia principal. Por lo tanto, el tiempo de ejecución de la transacción en la réplica se convierte en la latencia de replicación. Durante este periodo, otras transacciones confirmadas en la instancia principal no se aplican en la réplica, lo que retrasa la actualización de los datos.

Optimización mediante aplicación en tiempo real para transacciones grandes (diagrama derecho): la optimización principal consiste en ejecutar la transacción grande de manera simultánea en la réplica y en la instancia principal. Si la transacción se confirma en la instancia principal, también se confirma en la réplica. De igual forma, si se revierte en la instancia principal, se revierte en la réplica.

Requisitos previos

Para usar la función de aplicación en tiempo real para transacciones grandes, su instancia debe cumplir con a continuación requisito:

Versión del motor de base de datos: MySQL 8.0 con una versión secundaria del motor 20260228 o posterior. Si su instancia no cumple este requisito, puede upgrade the minor engine version o upgrade the database engine version.

Procedimiento

Vaya a la página Instances. En la barra de navegación superior, seleccione la región donde reside la instancia RDS. Luego, busque la instancia RDS y haga clic en su identificador.
En el panel de navegación izquierdo, haga clic en Parameters.

En la pestaña Editable Parameters, busque y configure a continuación los a continuación parámetros:

Habilitar la función de aplicación en tiempo real para transacciones grandes:
1. Establezca loose_binlog_realtime_apply_long_trx_enabled en ON.
2. Establezca loose_binlog_realtime_transmit_source_enabled en ON.
3. Establezca loose_binlog_realtime_transmit_replica_enabled en ON.

Otros parámetros obligatorios:

Parámetro	Descripción	Valor recomendado
`loose_binlog_realtime_replica_long_transaction_limit_size`	Define el umbral de tamaño que activa la replicación en tiempo real para una transacción. Cuando los eventos binlog generados por una transacción superan este valor, la función se activa automáticamente.	64 MB
`loose_binlog_realtime_enable_log_messag`	Indica si los registros de replicación en tiempo real se escriben en el registro de errores. Se recomienda habilitar este parámetro.	`ON`
loose_binlog_realtime_apply_workers	Controla la cantidad de subprocesos Brr Worker destinados a la replicación en tiempo real.	8

Haga clic en OK y luego en Submit Parameters. En el cuadro de diálogo que aparece, elija cuándo aplicar los cambios. Los cambios de parámetros surten efecto de inmediato sin necesidad de reiniciar la instancia.

Resultados de la optimización

El a continuación ejemplo muestra el efecto de esta función en una transacción de importación de datos que involucra 5 millones de filas en la instancia principal:

Antes de la optimización: la transacción se ejecuta primero en la instancia principal. Una vez confirmada, se aplica en la réplica. La latencia de replicación equivale al tiempo de ejecución de la transacción.
Después de la optimización: la transacción se ejecuta de forma simultánea en la instancia principal y en la réplica, lo que elimina la latencia de replicación.