En la replicación primaria-secundaria, el mecanismo predeterminado COMMIT_ORDER determina la reproducción en paralelo según si las transacciones se pueden confirmar en paralelo en la instancia RDS primaria. Esto limita el paralelismo de la reproducción a la concurrencia de dicha instancia. WRITESET elimina esta limitación al detectar conflictos de transacciones a nivel de fila, lo que reduce el retraso de replicación entre las instancias RDS primaria y secundaria.
Funcionamiento de WRITESET
Cuando se utiliza COMMIT_ORDER, dos transacciones solo se reproducen en paralelo si se confirman en paralelo en la instancia RDS primaria.
WRITESET comprueba si las filas de datos que modifica cada transacción entran en conflicto con las que modifican otras transacciones. Si no existen conflictos, las transacciones se reproducen en paralelo en la instancia RDS secundaria, sin importar cómo se hayan confirmado en la instancia RDS primaria.
Versiones compatibles
La instancia RDS debe ejecutar una de a continuación versiones de MySQL:
|
Versión de MySQL |
Versión mínima del motor secundario |
|
MySQL 5.7 |
20211231 |
|
MySQL 8.0 |
20210930 |
Habilite WRITESET
Establezca los tres parámetros siguientes. Para obtener instrucciones, consulte Modify instance parameters.
transaction_write_set_extraction = XXHASH64
binlog_transaction_dependency_tracking = WRITESET
binlog_transaction_dependency_history_size = 500000El parámetro binlog_transaction_dependency_history_size establece el número máximo de filas de datos almacenadas en memoria para la detección de conflictos. Un valor mayor rastrea más filas de datos y mejora el paralelismo.
Dependencias de parámetros
Los parámetros binlog_transaction_dependency_tracking y transaction_write_set_extraction se afectan mutuamente. Utilice las combinaciones válidas que se muestran a continuación. El sistema bloquea las combinaciones no válidas.
|
binlog_transaction_dependency_tracking |
transaction_write_set_extraction |
|
|
|
|
|
|
Referencia de parámetros
binlog_transaction_dependency_tracking
Determina cómo se reproducen en paralelo, en la instancia RDS secundaria, las transacciones registradas en los registros binarios.
La reproducción paralela multiproceso requiere que replica_parallel_workers o slave_parallel_workers sea mayor que 0.
|
Atributo |
Valor |
|
Predeterminado |
|
|
Valores válidos |
|
|
Versiones compatibles |
MySQL 5.7 (versión del motor secundario 20211231 y posteriores), MySQL 8.0 (versión del motor secundario 20210930 y posteriores) |
|
Valor |
Descripción |
|
|
Determina las dependencias según el orden de confirmación. Dos transacciones se reproducen en paralelo en la instancia RDS secundaria si se confirman en paralelo en la instancia RDS primaria. Este modo depende de la configuración de paralelismo de la instancia RDS primaria. |
|
|
Determina las dependencias a nivel de fila. Dos transacciones se reproducen en paralelo si no modifican la misma fila de datos de una tabla que tenga una clave primaria o única. Este modo no depende de la configuración de paralelismo de la instancia RDS primaria. |
|
|
Las transacciones de una misma sesión se reproducen de forma secuencial. Las transacciones de sesiones distintas siguen las mismas reglas que |
transaction_write_set_extraction
Especifica el algoritmo de hash que calcula el valor hash de una fila de datos. Este valor determina si distintas transacciones modifican la misma fila de datos.
|
Atributo |
Valor |
|
Predeterminado |
|
|
Valores válidos |
|
|
Versiones compatibles |
MySQL 5.7 (versión del motor secundario 20211231 y posteriores), MySQL 8.0 (versión del motor secundario 20210930 y posteriores) |
|
Valor |
Descripción |
|
|
No calcula el valor hash de las filas de datos. Cuando se configura este valor, se debe deshabilitar |
|
|
Calcula el valor hash de las filas de datos mediante un algoritmo de hash de 64 bits. |
binlog_transaction_dependency_history_size
Especifica el número máximo de filas de datos almacenadas en memoria para la detección de conflictos.
|
Atributo |
Valor |
|
Valor recomendado |
|
|
Efecto |
Un valor mayor rastrea más filas de datos y permite un mayor paralelismo. |
Cuándo deja de ser válido WRITESET
En ciertos escenarios, WRITESET recurre a COMMIT_ORDER para detectar conflictos de transacciones. Esta alternativa no degrada el rendimiento de la reproducción en paralelo en la instancia RDS secundaria.
WRITESET deja de ser válido cuando ocurre lo siguiente:
Se ejecutan operaciones DDL
Se confirman transacciones grandes
Se modifican tablas con claves externas
Existen tablas sin claves primarias
Si hay un retraso de replicación entre sus instancias RDS secundarias y de solo lectura, habilite WRITESET para reducirlo.
Referencias
Use the parameter diagnostics feature para obtener recomendaciones de optimización de parámetros.
-
Documentación oficial de MySQL: