Can MySQL Semi‑Sync Replication Keep Up? A Sysbench Performance Test

Test environment

Two Dell DL380 G7 servers in master‑slave mode, each with 12 physical CPU cores, 32 GB RAM (InnoDB pool size 20 GB), two ordinary HDDs, RAID cache enabled, running MySQL 5.6.19. The benchmark tool is sysbench.

Key conclusions

MySQL semi‑synchronous replication improves data consistency but its throughput is far lower than asynchronous replication; the same script yields about 3,000 TPS versus over 10,000 TPS for async.

The standby server’s recovery capability is weak because replication runs single‑threaded while the master processes transactions concurrently; sharding can help by allowing multi‑threaded recovery.

Scenario 1 – Transaction rate with semi‑sync replication

Traditional asynchronous replication sends binlog to the slave without waiting for acknowledgment, risking data loss if the master fails. MySQL 5.5 introduced semi‑sync replication, where the slave must write the received binlog to its relay log and acknowledge receipt, improving safety at the cost of performance.

Relevant parameters

sync_binlog=1 innodb_flush_log_at_trx_commit=1 innodb_flush_method=O_DIRECT rpl_semi_sync_master_enabled=1 rpl_semi_sync_master_timeout=1000 rpl_semi_sync_slave_enabled=1

A single transaction consists of one INSERT, three UPDATEs and one DELETE.

Test script

sysbench --test=oltp --mysql-table-engine=innodb --oltp-table-size=10000000 --oltp-distinct-ranges=0 --mysql-db=test --mysql-user=root --mysql-password=123456 --oltp-order-ranges=0 --oltp-range-size=100 --oltp-point-selects=0 --oltp-simple-ranges=0 --oltp-sum-ranges=0 --oltp-test-mode=complex --max-requests=2000000 --num-threads=25 --max-time=40 run

Results

Asynchronous replication achieved more than 10,000 TPS.

Semi‑synchronous replication peaked near 3,000 TPS, showing a significant performance gap.

If the network glitches, semi‑sync falls back to async and automatically resumes semi‑sync once the network recovers.

In a dual‑master setup, both nodes can be configured for semi‑sync.

Scenario 2 – Replication lag on the slave

Relevant parameter

slave_parallel_workers=4

Results

The master performed 37,792 DML operations per second, while the slave replicated at 8,745 ops/s.

MySQL replication for a single database is single‑threaded, causing the large speed disparity.

When the master exceeds roughly 8,000 DML ops/s, noticeable replication delay appears; additional read queries on the slave exacerbate the lag.

Sharding the system and enabling parallel replication can boost replication speed by about 70 % per additional worker thread.

Source: ITpub technical blog (author wei‑xh).