Primary Replica Sync
Primary replica sync is the message-level protocol by which a primary database node ships its write-ahead log (WAL) or binary log entries to one or more replica nodes, keeping their data in step with the primary.
Primary replica sync is the message-level protocol by which a primary database node ships its write-ahead log (WAL) or binary log entries to one or more replica nodes, keeping their data in step with the primary.
This sequence diagram traces a single write operation from client submission through to replica acknowledgment. The client sends a write to the Primary. The primary validates the transaction and appends the change to its Write-Ahead Log (WAL) before applying the change to its local storage. This ordering is critical: logging before applying means the change can be replayed if the primary crashes mid-write.
Once logged, the primary sends the log segment to the Replica. In PostgreSQL streaming replication this happens via a persistent replication slot connection; in MySQL it is the binlog dump protocol. The replica writes the received segment to its own standby WAL and sends back an acknowledgment containing its current log sequence number (LSN). The primary tracks each replica's LSN to know how far behind it is — this is the replication lag.
In synchronous mode (shown in the diagram), the primary waits for this acknowledgment before replying to the client. This guarantees that at least one replica holds the data even if the primary is lost immediately after the commit. In asynchronous mode, the primary skips the wait and replies to the client before the replica has confirmed receipt.
Understanding this flow matters when reasoning about failover. If the primary fails before an async replica acknowledges the last WAL segment, those writes are lost. Tools like Patroni or AWS RDS Multi-AZ enforce synchronous replication to a standby to make the Database Failover process lossless. See Database Replication for the broader topology this sync process operates within.