Databases 13 min read

Understanding MySQL Multi‑Threaded Slave (MTS) Parallel Replication Mechanism

This article explains the internal workflow of MySQL's multi‑threaded slave (MTS) parallel replication, covering the coordination thread, logical‑clock sub‑mode, worker allocation, waiting states, key configuration parameters, and illustrative code snippets and log analysis.

Aikesheng Open Source Community
Aikesheng Open Source Community
Aikesheng Open Source Community
Understanding MySQL Multi‑Threaded Slave (MTS) Parallel Replication Mechanism

The article introduces MySQL's Multi‑Threaded Slave (MTS) parallel replication, focusing on the logical‑clock sub‑mode where the original SQL thread becomes a coordination thread that also handles checkpointing.

Two sub‑modes are mentioned: Mts_submode_logical_clock and Mts_submode_database , but the discussion is limited to the logical‑clock approach. Required parameters are slave_parallel_type=LOGICAL_CLOCK and slave_parallel_workers=4 ; setting the workers to 0 disables MTS.

The coordination thread decides whether a transaction can be replayed in parallel and assigns it to a worker thread. Parallel replay is allowed when last_committed <= current_lwm ; otherwise the coordination thread waits for dependent transactions to commit.

Key metadata tables when master_info_repository and relay_log_info_repository are set to TABLE are slave_master_info , relay_log_info_repository , and slave_worker_info . The article also describes how the checkpoint information is stored and later shown in SHOW SLAVE STATUS .

Worker allocation uses Mts_submode_logical_clock::get_least_occupied_worker . If a worker has an empty job queue it is selected; otherwise the coordination thread may wait for a free worker or for its queue to have space (queue size = 16384). The code snippets show the enqueue logic, condition variables, and handling of queue overfill.

Various waiting states are detailed: "Waiting for dependent transaction to commit", "Waiting for slave workers to process their queues", "Waiting for Slave Worker queue", and "Waiting for Slave Workers to free pending events" (the latter caused by very large events). Log output examples illustrate how these waits are reported, including statistics such as seconds elapsed, events assigned, and overrun/overfill counts.

An example binary‑log segment generated with the WRITESET method demonstrates how last_commit and seq_number are used to decide parallel execution. The article shows that smaller last_commit values increase parallelism, but large unfinished transactions can raise current_lwm and block subsequent transactions.

Finally, the author recommends further reading in his book "深入理解 MySQL 主从原理 32 讲" for an in‑depth study of MySQL replication.

MySQLDatabase InternalsGTIDMTSparallel replication
Aikesheng Open Source Community
Written by

Aikesheng Open Source Community

The Aikesheng Open Source Community provides stable, enterprise‑grade MySQL open‑source tools and services, releases a premium open‑source component each year (1024), and continuously operates and maintains them.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.