In this lesson, you will learn how the requirement for replica acknowledgment introduces a latency penalty that directly impacts transaction performance.
When you configure a database for high availability, you often use replication to keep a copy of your data on a secondary server. In synchronous replication, the primary database is not allowed to consider a transaction "committed" until it has received confirmation that the secondary node has successfully written the change to its own log.
The Latency Penalty
In a standard, non-replicated setup, a COMMIT command is finished as soon as the primary database confirms the data is safely written to its own local Write-Ahead Log (WAL).
In synchronous replication, the workflow adds a critical "round trip" step:
- Client sends
COMMIT. - Primary writes to its local log.
- Primary sends the data to the secondary.
- Primary waits for the secondary to write to its log and send back an acknowledgment.
- Primary tells the client, "Transaction successful."
If the network between your servers has even a small delay (e.g., 5 milliseconds), that delay is added to every single write operation. If you perform many small transactions in a loop, your application will feel significantly slower because it is bound by the speed of the network rather than the speed of your local disk.
Illustrative Example
Imagine a banking application executing a transfer:
BEGIN;
UPDATE accounts SET balance = balance - 100 WHERE id = 1;
UPDATE accounts SET balance = balance + 100 WHERE id = 2;
COMMIT; -- The app hangs here until the secondary server replies!
If the secondary server experiences a temporary network spike or high disk load, the COMMIT operation on the primary will hang. This creates a trade-off: you gain perfect data durability across your cluster (ensuring no data is lost during failover), but you pay for it with increased response times for your end users. If the latency between nodes is high, synchronous replication can quickly become a bottleneck, potentially causing your connection pool to exhaust as threads wait indefinitely for those acknowledgments.
Key Takeaway: Synchronous replication prioritizes data safety over speed by forcing the primary database to wait for a round-trip network acknowledgment, effectively binding your transaction latency to the speed of your network and secondary server.