Semi-Synchronous Replication

Synchronous replication gives you zero data loss. Beautiful. But what happens when you have three replicas and one of them is temporarily slow, maybe it is running a backup, or its disk is doing garbage collection?

In fully synchronous mode, the primary waits for ALL replicas. So your fastest two replicas confirm in 2ms, but the slow one takes 800ms. Your write latency? 800ms. One sluggish replica holds the entire system hostage.

That is why MySQL introduced semi-synchronous replication, and it has become one of the most widely deployed replication modes in production. The idea is dead simple: wait for at least ONE replica to confirm, then acknowledge the write. The rest can catch up asynchronously.

You get the durability guarantee of synchronous replication (data on at least two machines) without the availability problem (one slow replica does not block everything). Meta uses semi-sync replication across their MySQL fleet. So does Uber. So does Booking.com. Pinterest runs it on their core MySQL clusters to protect against data loss during regional failovers.

The flow:

1. Client sends a write to the primary
2. Primary writes to its local WAL (relay log in MySQL)
3. Primary sends WAL to all replicas in parallel
4. Primary waits until at least one replica acknowledges receipt
5. Primary confirms the write to the client
6. Remaining replicas continue applying changes asynchronously

If that one fast replica confirms in 1ms but the other two take 500ms, the client gets "success" in 1ms. The remaining replicas catch up on their own schedule.

The fallback behavior matters. MySQL's rpl_semi_sync_master_timeout controls how long the primary waits. If no replica confirms within that timeout (default: 10 seconds), the primary falls back to async mode. This prevents the primary from hanging forever if all replicas are down, but it means you lose your durability guarantee during that degraded state.

MySQL 5.7 added rpl_semi_sync_master_wait_for_slave_count, which lets you require confirmation from N replicas instead of just one. Setting it to 2 means data must exist on three machines (primary + 2 replicas) before the client hears "success." Meta's MySQL deployment uses this to guarantee two-replica confirmation for critical transaction paths.