Tune the multi-threaded replica (replica_parallel_workers)

Command

-- 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;

What it does

Sets the number of workers that apply transactions in parallel on the replica; replica_preserve_commit_order keeps the commit order identical to the source. WRITESET dependency tracking on the source lets transactions that touch different rows be applied in parallel even if they were committed serially on the source.

When to use it

When the replica cannot keep up with the source write rate and lag builds up while the applier is effectively single-threaded.

Caution

A new worker count takes effect when the applier restarts. Running more workers than CPU cores adds coordination overhead; start in the 8–16 range and watch lag and worker errors. A single huge transaction or heavy DML on a table without a PK cannot be parallelized, which is usually the real cause of persistent lag. replica_preserve_commit_order=OFF gives more parallelism but allows brief out-of-order commits on the replica; keep it ON on replicas that serve reads.