Régler la réplique multi-thread (replica_parallel_workers)

Commande

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

Ce que fait la commande

Fixe le nombre de workers qui appliquent les transactions en parallèle sur la réplique ; replica_preserve_commit_order conserve un ordre de commit identique à celui de la source. Le suivi des dépendances WRITESET sur la source permet d'appliquer en parallèle des transactions touchant des lignes différentes, même si elles ont été validées en série sur la source.

Quand l'utiliser

Lorsque la réplique ne suit pas le débit d'écriture de la source et que le retard s'accumule alors que l'applier fonctionne en pratique sur un seul thread.

Attention

Un nouveau nombre de workers prend effet au redémarrage de l'applier. Utiliser plus de workers que de cœurs CPU ajoute une surcharge de coordination ; commencez dans la plage 8–16 et surveillez le retard et les erreurs des workers. Une seule transaction énorme ou des DML lourds sur une table sans PK ne peuvent pas être parallélisés, ce qui est généralement la vraie cause d'un retard persistant. replica_preserve_commit_order=OFF donne plus de parallélisme mais autorise de brefs commits hors ordre sur la réplique ; laissez-le à ON sur les répliques qui servent des lectures.