Настроить многопоточную реплику (replica_parallel_workers)

Команда

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

Что делает

Задаёт число рабочих процессов, параллельно применяющих транзакции на реплике; replica_preserve_commit_order сохраняет порядок commit идентичным источнику. Отслеживание зависимостей WRITESET на источнике позволяет параллельно применять транзакции, затрагивающие разные строки, даже если на источнике они фиксировались последовательно.

Когда использовать

Когда реплика не успевает за скоростью записи источника и накапливается отставание, а applier фактически работает в один поток.

Внимание

Новое число рабочих процессов вступает в силу при перезапуске applier. Больше рабочих процессов, чем ядер CPU, — это лишние накладные расходы на координацию; начните с диапазона 8–16 и следите за отставанием и ошибками рабочих процессов. Одну огромную транзакцию или интенсивный DML на таблице без PK распараллелить нельзя, и обычно именно это — настоящая причина устойчивого отставания. replica_preserve_commit_order=OFF даёт больше параллелизма, но допускает кратковременное нарушение порядка commit на реплике; на репликах, обслуживающих чтение, держите ON.