Semi-Synchronous Replication

In this lesson, you will learn how to configure semi-synchronous replication nodes to guarantee that your database writes are safely captured by at least one replica before they are committed.

The Problem: Asynchronous Risks

In standard asynchronous replication, the source server writes a transaction to its binary log and immediately tells the client the operation is successful. The replica eventually pulls that data. If the source crashes after the acknowledgment but before the replica receives the transaction, you face data loss.

The Solution: Semi-Synchronous Replication

Semi-synchronous replication introduces a "wait-and-verify" mechanism. When a transaction is committed on the source, the source waits for at least one configured replica to acknowledge that it has received the transaction and written it to its own relay log. Only after that acknowledgment is received does the source return a "success" message to the application.

Configuration Essentials

To implement this, you must first ensure the rpl_semi_sync_master and rpl_semi_sync_slave plugins are loaded. Once active, you configure the nodes using these primary system variables:

1. rpl_semi_sync_master_enabled: Set this to ON on the primary to initiate the semi-sync protocol.
2. rpl_semi_sync_master_wait_for_slave_count: Defines how many replicas must confirm receipt before the primary proceeds. Setting this to 1 is the standard for high availability.
3. rpl_semi_sync_master_timeout: This is a critical safety setting. If the replica does not acknowledge the transaction within the specified milliseconds (e.g., 1000ms), the primary reverts to standard asynchronous mode to prevent hanging your entire application.

-- Enable on the primary node
SET GLOBAL rpl_semi_sync_master_enabled = 1;

-- Require at least one replica to acknowledge
SET GLOBAL rpl_semi_sync_master_wait_for_slave_count = 1;

-- Failover to async if no acknowledgement within 1 second
SET GLOBAL rpl_semi_sync_master_timeout = 1000;

By configuring these variables, you bridge the gap between pure performance (asynchronous) and absolute data integrity (synchronous), ensuring that every committed transaction has a durable "backup" sitting on a replica's disk.

Key Takeaway: Semi-synchronous replication trades a slight increase in write latency for a significantly higher guarantee that committed transactions will not be lost during a primary server failure.