Ajustar la réplica multi-threaded (replica_parallel_workers)

Comando

-- Replica: stop the applier, set worker count and commit order
STOP REPLICA SQL_THREAD;
SET PERSIST replica_parallel_workers = 8;
SET PERSIST replica_preserve_commit_order = ON;
START REPLICA SQL_THREAD;
SELECT COUNT(*) AS workers FROM performance_schema.replication_applier_status_by_worker;

-- Source (8.0 only): switch dependency tracking to WRITESET (default in 8.4, variable removed)
SET PERSIST binlog_transaction_dependency_tracking = WRITESET;

Qué hace

Define el número de workers que aplican transacciones en paralelo en la réplica; replica_preserve_commit_order mantiene el orden de commit idéntico al del origen. El seguimiento de dependencias WRITESET en el origen permite aplicar en paralelo transacciones que tocan filas distintas aunque se hayan confirmado en serie en el origen.

Cuándo usarlo

Cuando la réplica no puede seguir el ritmo de escritura del origen y el lag se acumula mientras el applier funciona en la práctica con un solo thread.

Precaución

Un nuevo número de workers surte efecto cuando se reinicia el applier. Ejecutar más workers que núcleos de CPU añade sobrecarga de coordinación; empiece en el rango de 8–16 y vigile el lag y los errores de los workers. Una sola transacción enorme o un DML pesado sobre una tabla sin PK no se pueden paralelizar, y suelen ser la causa real de un lag persistente. replica_preserve_commit_order=OFF da más paralelismo pero permite breves commits fuera de orden en la réplica; manténgalo en ON en las réplicas que sirven lecturas.