How MySQL Parallel Replication Evolved: Strategies from 5.5 to 5.7

Background

MySQL replication has historically been single‑threaded apply on the replica, limiting concurrency.

Basic Idea of Parallel Replication

Convert the single sql_thread into a dispatcher that hands work to multiple worker_thread s. The replica has two main threads: io_thread (fetches binlog to relay log) and sql_thread (reads relay log and applies). Parallel replication makes sql_thread a dispatcher.

All implementations follow this, differing only in the dispatch strategy.

Dispatch strategies fall into two categories: using the traditional binlog format or modifying the binlog to add extra information.

MySQL 5.5 (no official support)

Alibaba created its own parallel replication for 5.5, keeping the binlog format unchanged. It supports two dispatch strategies: table‑level and row‑level.

Table‑level dispatch : Uses Table_map events in row‑format binlog to obtain database and table names. Updates to different tables can be applied out of order, while updates to the same table are hashed to the same worker to preserve order. Works well for workloads updating many tables, but degrades when a hot table dominates.

Row‑level dispatch : Uses primary‑key values from row‑format binlog. Hash key = database+table+primary‑key, ensuring rows with the same primary key go to the same worker. Requires a primary key; without it the strategy cannot be used. Suitable for hot‑table scenarios but incurs higher CPU and memory cost for large transactions.

MySQL 5.6 (official support)

Official 5.6 adds a database‑level dispatch strategy. It groups statements by database name, giving a simple hash key. Advantages: works with any binlog format and can be applied by moving tables to different databases. It is faster because the hash key is short, but its usefulness is limited to workloads that can be split by database.

MariaDB

MariaDB offers several parallel replication options; the default “CONSERVATIVE” mode is commonly used in production. MariaDB supports multi‑master replication and adds a domain_id field to identify the source master. Transactions from the same master share a commit_id, allowing them to be applied in parallel because they are assumed not to conflict.

The main drawback is the “slow‑transaction” problem: a large transaction can block later groups that are otherwise independent, similar to the issue seen in MySQL 5.7.

MySQL 5.7 (official support)

MySQL 5.7 adopts the MariaDB strategy and refines it. It treats a transaction’s lifecycle as three phases—prepare, committing, and committed—allowing transactions that are in different phases but share the same commit_id to run concurrently. This improves concurrency compared with the earlier group‑based approach.

Example comparison shows that the 5.7 strategy can start later groups earlier, reducing overall replication lag, though very large transactions can still become “drag‑behind” bottlenecks.

Key Takeaways

Dispatch granularity progresses from database → table → row, with increasing parallelism and overhead. Commit‑id based strategies cover a broader range of workloads with lower extra cost but still suffer from large‑transaction drag‑behind effects. Choosing the right strategy depends on the application’s update patterns and the architect’s judgment.