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

O que faz

Define o número de workers que aplicam transações em paralelo na réplica; replica_preserve_commit_order mantém a ordem de commit idêntica à da source. O rastreamento de dependências WRITESET na source permite que transações que tocam linhas diferentes sejam aplicadas em paralelo mesmo que tenham sido confirmadas em série na source.

Quando usar

Quando a réplica não acompanha a taxa de gravação da source e o lag se acumula enquanto o applier é, na prática, single-threaded.

Atenção

Um novo número de workers tem efeito quando o applier reinicia. Rodar mais workers do que núcleos de CPU adiciona overhead de coordenação; comece na faixa de 8–16 e observe o lag e os erros dos workers. Uma única transação enorme ou DML pesado em uma tabela sem PK não pode ser paralelizado, o que normalmente é a causa real de um lag persistente. replica_preserve_commit_order=OFF dá mais paralelismo, mas permite commits momentaneamente fora de ordem na réplica; mantenha ON nas réplicas que atendem leituras.