Semi-synchronous replication is a database replication mode in which the primary waits for at least one replica to confirm receipt of a transaction’s changes before reporting the commit as successful to the client, but does not wait for the replica to apply them. In replication it sits between asynchronous and fully synchronous replication, and in databases such as MySQL and MariaDB it is the standard way to reduce data loss on failover without paying the full latency cost of synchronous commits.
The guarantee is precise: after a successful commit, the transaction exists in durable storage on the primary and in the relay log of a replica. If the primary then fails, a promoted replica can still obtain the transaction, provided failover is handled correctly.
How semi-synchronous replication acknowledges commits
In a semi-synchronous setup, the commit path of a primary-replica system gains one extra step: a network acknowledgment from a replica. The primary writes the transaction to its binary log, ships the events to its replicas and blocks the client session until enough replicas reply that the events are safely written to their relay logs.
The sequence below shows the lossless variant used by default in modern MySQL.
- The client issues
COMMITand the primary prepares the transaction in the storage engine. - The primary writes and syncs the binary log entry.
- Events are sent to the replicas, which write them to the relay log and return an acknowledgment.
- After the required number of acknowledgments, the primary commits in the storage engine and replies to the client.
- Replicas apply the relay log events later, at their own pace.
Because applying is still asynchronous, replication lag on reads is not eliminated. A read replica may confirm receipt and still return old data for a short time afterward, which surprises teams that expect read-after-write consistency.
Key configuration parameters
Semi-synchronous behavior is controlled by a few parameters that decide durability, latency and availability. In MySQL 8.0.26 and later the variables use the rpl_semi_sync_source_ and rpl_semi_sync_replica_ prefixes; older versions and MariaDB use the master and slave names.
| Parameter | Default | Effect |
|---|---|---|
rpl_semi_sync_source_enabled | OFF | Turns on semi-sync on the primary |
rpl_semi_sync_replica_enabled | OFF | Lets a replica send acknowledgments |
rpl_semi_sync_source_timeout | 10000 ms | Wait before falling back to async |
rpl_semi_sync_source_wait_for_replica_count | 1 | Acknowledgments required per commit |
rpl_semi_sync_source_wait_point | AFTER_SYNC | When the primary waits in the commit path |
The wait point is the most important durability setting. With AFTER_SYNC, the primary waits before committing in the engine, so no other session can see a transaction that replicas have not received. With the older AFTER_COMMIT, other sessions may read data that would be lost on failover, a so-called phantom read after failover.
MariaDB has shipped semi-synchronous replication built into the server since version 10.3, while older MySQL and MariaDB releases load it as a plugin. In both systems, a replica only counts toward the acknowledgment set when semi-sync is enabled on it and its I/O thread has been restarted, so verifying the status variables on every node is part of any rollout.
Semi-synchronous compared with other replication modes
The replication modes differ in what the primary waits for before confirming a commit, and that single choice drives their latency, durability and availability behavior.
| Mode | Primary waits for | Data loss on primary failure | Commit latency |
|---|---|---|---|
| Asynchronous replication | Nothing | Possible, up to the lag | Lowest |
| Semi-synchronous replication | Receipt by N replicas | None while semi-sync is active | Plus one network round trip |
| Synchronous replication | Commit or apply on replicas | None | Highest |
| Quorum-based consensus | Majority of nodes | None for acknowledged writes | Plus one majority round trip |
PostgreSQL offers comparable behavior through `synchronous_commit` levels. Setting it to remote_write waits until the standby has written the WAL to its operating system, which is close to MySQL semi-sync, while on waits for a flush to disk and remote_apply waits until the change is visible on the standby. Consensus systems based on Raft go further by tying commit acknowledgment to leader election.
Latency, timeouts and topology choices
Every semi-synchronous commit costs at least one round trip to the fastest acknowledging replica. Within one data center this usually adds well under a millisecond to a few milliseconds, while a replica in another region can add tens of milliseconds per commit, which limits single-session write throughput sharply.
| Situation | Recommended setup | Reason |
|---|---|---|
| Two replicas in the same data center | Wait for 1 acknowledgment | Low latency, one failure tolerated |
| Replicas across availability zones | Wait for 1 of 2 zones | Survives a zone outage with modest latency |
| Cross-region disaster recovery | Async to the remote region | Avoids long commit delays |
| Strict zero-loss requirement | Long timeout plus monitoring | Prefer stalling over silent fallback |
The timeout is a trade-off between availability and durability. When no replica answers in time, MySQL silently falls back to asynchronous mode and keeps accepting writes. A short timeout keeps the application available but reopens the window for data loss; a very long timeout protects data but makes the primary hang if replicas disappear.
Pitfalls and misconceptions
Semi-synchronous replication is often trusted for more than it actually guarantees.
- Silent fallback: after a timeout the cluster runs asynchronously until replicas catch up; monitor the status variable
Rpl_semi_sync_source_status. - Received is not applied: replicas may still serve stale reads.
- Failover must choose the right replica: only a replica that acknowledged the last transactions holds them.
- No split-brain protection: semi-sync alone does not prevent two primaries; fencing or a quorum mechanism is still required.
- Throughput drops with distance: high-latency replicas in the acknowledgment set slow every commit.
The idea in brief
Imagine an office that sends a copy of every signed contract to a second office. Normally the first office does not wait for any reply. With semi-synchronous replication, it waits for word that the copy arrived before telling the customer the deal is done.
The second office may file the copy a little later. What matters is that the copy already exists somewhere else. If the first office burns down, no confirmed contract is lost.
A practical scenario
An online payment service runs MySQL with one primary and two replicas in two availability zones of the same region. Before the change, replication is asynchronous, and a primary crash during a peak once lost several seconds of confirmed orders that had not yet reached any replica.
The team enables semi-synchronous replication with AFTER_SYNC, one required acknowledgment and a 2-second timeout, and adds an alert on fallback to async mode. Commit latency rises by about 1 to 2 ms, which customers do not notice. In the next failover test, the orchestration tool promotes the replica that acknowledged the latest transactions, and no confirmed payment is lost.