Cuando el registro binario está habilitado, una transacción grande puede monopolizar la cola de escritura de binlog e impedir que todas las demás transacciones se confirmen. Esto provoca una cascada de latencia de escritura, aumentos de consultas lentas y picos de conexiones. PolarDB for MySQL ofrece escritura optimizada de binlog para transacciones grandes. Esta función redirige los datos de binlog de las transacciones grandes a un archivo dedicado, de modo que las demás transacciones puedan confirmarse sin esperas.
Versiones compatibles
Esta función requiere PolarDB for MySQL Enterprise Edition o Standard Edition con una de las versiones del motor de base de datos que se indican a continuación:
PolarDB for MySQL 8.0.1, versión de revisión 8.0.1.1.42 o posterior
PolarDB for MySQL 8.0.2, versión de revisión 8.0.2.2.25 o posterior
Para comprobar la versión del motor de su clúster, consulte la sección "Consultar una versión del motor" de Engine versions 5.6, 5.7, and 8.0.
Casos de uso
Habilite esta función cuando las transacciones grandes se ejecuten junto con otras transacciones en el mismo clúster. Es adecuada para los escenarios que se describen a continuación:
Clústeres con cargas de trabajo mixtas: Las escrituras por lotes grandes o las importaciones masivas de datos coexisten con transacciones OLTP.
Cargas de trabajo sensibles a la latencia: Debe evitar que las confirmaciones de transacciones grandes provoquen picos de latencia o aumentos de consultas lentas en transacciones concurrentes.
Prevención de aumentos de conexiones: Las confirmaciones de transacciones grandes están provocando reintentos en la aplicación y picos en el número de conexiones.
Cómo funciona
En el momento de la confirmación, cada transacción vuelca sus datos de binlog desde la caché de binlog en memoria al archivo de binlog compartido. Cuando varias transacciones se confirman al mismo tiempo, se ponen en cola para esta escritura. Si una transacción —por ejemplo, una transacción con 1 GB de datos de binlog— retiene la cola durante un periodo prolongado, todas las demás transacciones en la cola deben esperar. Esto produce una cascada de problemas: aumentan las consultas lentas, los bloqueos de escritura se mantienen durante más tiempo, las aplicaciones reintentan operaciones con errores y se disparan los recuentos de conexiones.
Una vez que habilite la función, PolarDB for MySQL redirige los datos de binlog de cualquier transacción grande que cumpla los requisitos a un archivo de binlog dedicado. Esto evita que la transacción grande bloquee a otras transacciones en la cola de escritura, para que las transacciones concurrentes puedan confirmarse sin esperas.
El archivo de binlog dedicado tiene un encabezado estándar que incluye FORMAT_DESCRIPTION_EVENT y PREVIOUS_GTIDS_LOG_EVENT. También incluye un marcador de posición especial llamado IGNORABLE_LOG_EVENT, que los sistemas descendentes ignoran automáticamente.
Habilite la escritura optimizada de binlog
Establezca loose_enable_large_trx_optimization en ON para habilitar la función. Utilice loose_binlog_large_trx_threshold_up para establecer el umbral de tamaño de binlog que desencadena la optimización.
Ambos parámetros surten efecto de inmediato sin reiniciar el clúster.
Para obtener instrucciones sobre cómo establecer parámetros, consulte Configure los parámetros del clúster y del nodo.
|
Parámetro |
Ámbito |
Valor predeterminado |
Valores válidos |
Descripción |
|
|
Global |
OFF |
OFF, ON |
Habilita o deshabilita la escritura optimizada de binlog para transacciones grandes. |
|
|
Global |
1 GB |
10 MB–300 GB |
Umbral de tamaño de binlog por encima del cual una transacción se escribe en un archivo de binlog dedicado en lugar del archivo de binlog compartido. |
Limitaciones
Los nodos de réplica descendentes no pueden usar la replicación multihilo basada en la concurrencia de la base de datos cuando esta función está habilitada. No establezca slave_parallel_workers>0 y slave_parallel_type='DATABASE' al mismo tiempo. En su lugar, puede usar slave_parallel_workers>0 y slave_parallel_type='logical_clock'.
Se aplica la limitación adicional que se muestra a continuación:
La suma de comprobación no es compatible con los archivos de binlog de las transacciones grandes.
Comparación de rendimiento
La figura que se muestra a continuación indica el tiempo necesario para confirmar transacciones grandes en un clúster que usa el tipo de almacenamiento PSL5, antes y después de habilitar la función.
Después de habilitar la función, el tiempo de confirmación de las transacciones grandes disminuye considerablemente. Esto elimina la alta carga de E/S y los bloqueos de escritura prolongados que las confirmaciones de transacciones grandes provocaban anteriormente.