Multi-Threaded Replica optimieren (replica_parallel_workers)

Befehl

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

Was es tut

Setzt die Anzahl der Worker, die Transaktionen auf der Replica parallel anwenden; replica_preserve_commit_order hält die Commit-Reihenfolge identisch zur Quelle. WRITESET-Abhängigkeitserkennung auf der Quelle erlaubt es, Transaktionen, die verschiedene Zeilen betreffen, parallel anzuwenden, selbst wenn sie auf der Quelle seriell committet wurden.

Wann einsetzen

Wenn die Replica mit der Schreibrate der Quelle nicht mithält und sich Lag aufbaut, während der Applier faktisch single-threaded arbeitet.

Vorsicht

Eine neue Worker-Anzahl wirkt, wenn der Applier neu startet. Mehr Worker als CPU-Kerne erzeugen Koordinations-Overhead; beginne im Bereich 8–16 und beobachte Lag und Worker-Fehler. Eine einzelne riesige Transaktion oder schweres DML auf einer Tabelle ohne PK lässt sich nicht parallelisieren, was meist die eigentliche Ursache dauerhaften Lags ist. replica_preserve_commit_order=OFF bringt mehr Parallelität, erlaubt aber kurzzeitig Commits außer der Reihe auf der Replica; auf Replicas, die Lesezugriffe bedienen, auf ON lassen.