Understanding MySQL MTS (Enhanced Multi‑Threaded Slave) and DTLE Configuration for Parallel Replication

MySQL replication lag was a long‑standing issue in early versions; MySQL 5.6.3 added parallel replication and MySQL 5.7 further refined it with the feature called enhanced multi‑threaded slave (MTS) , which significantly reduces delay.

The DTLE (Data Transfer Layer Engine) project added internal support for MTS parallel replay (issue #211). The source code is available at https://github.com/actiontech/dtle .

Key MTS principles :

Transactions that belong to the same group_commit can be replayed in parallel because they reach the prepare stage without conflicts.

Each transaction receives a monotonic sequence number (SeqNum) in the binlog; the last committed transaction of a group is recorded as LastCommit (LC) .

Transactions with the same LC can be replayed concurrently; transactions with a larger LC must wait until the previous group finishes.

MySQL 8.0 introduces WriteSet parallel replay, which is discussed separately.

Enabling MTS in MySQL 5.7 requires setting the following global variables:

-- group_commit wait time (larger value increases parallelism, may cause idle wait)
set global binlog_group_commit_sync_delay = 10000;   -- 10 ms
set global binlog_group_commit_sync_no_delay_count = 32;   -- ≤ thread count

Configuring DTLE for MTS involves editing the job.json file and setting ParallelWorkers to the desired number of parallel threads, e.g.:

{
  "Type": "Dest",
  "NodeName": "udup1",
  "Driver": "MySQL",
  "Config": {
    "Gtid": "",
    "ApproveHeterogeneous": true,
    "ReplChanBufferSize": 600,
    "ParallelWorkers": 16,
    "ConnectionConfig": {
      "Host": "127.0.0.1",
      "Port": 3308,
      "User": "root",
      "Password": "password"
    }
  }
}

Observing MTS binlog entries can be done with the mtswatcher tool (source dtle/helper/mtswatcher/mtswatcher.go ). Example commands:

cd dtle
make mtswatcher
./dist/mtswatcher -host 127.0.0.1 -port 3308 -user root -password password
# or specify a GTID
./dist/mtswatcher -host 127.0.0.1 -port 3308 -user root -password password -gtid "f2a4aa16-c8e6-11e7-9ff0-e19f7778f563:1-860460"

Sample output shows LC values and the number of transactions belonging to each LC, e.g.:

lc:4065    nTxOfThisLc:16 totalTx:4077
lc:4081    nTxOfThisLc:16 totalTx:4093
lc:4097    nTxOfThisLc:6  totalTx:4099
lc:4103    nTxOfThisLc:1  totalTx:4100
lc:4104    nTxOfThisLc:16 totalTx:4116
lc:4120    nTxOfThisLc:16 totalTx:4132

Version notes :

MTS works from 5.7 back to 5.6 and even earlier (5.6 → 5.*).

If a transaction’s sequence number is 0, it is treated as a 5.6 binlog entry and replayed in order.

Simple performance test generated 64 000 rows (parallelism = 64) and measured replay times:

Parallel replay of 4 000 rows with ParallelWorkers": 16 took 1 m 21 s , achieving roughly a 6× speed increase over single‑threaded replay (9 815 rows vs. 8 942 rows in the same interval).

Conclusion : DTLE not only optimizes data transfer but also improves MySQL 5.7 MTS replay speed; by configuring appropriate MTS parameters on the source MySQL instance and providing a proper DTLE job configuration, users can significantly accelerate data replication.