Database replication creates copies of data across multiple servers, providing both high availability and read scalability. Choosing the right replication strategy depends on your requirements for data consistency, latency tolerance, and failover speed.
Synchronous vs Asynchronous Replication
Synchronous replication guarantees that data is written to both the primary and replica before confirming the transaction to the client. This ensures zero data loss during failover but adds latency to every write operation. The performance impact is directly proportional to the network latency between primary and replica, making synchronous replication best suited for replicas in the same data center.
Asynchronous replication applies changes to the replica after they are committed on the primary, introducing a small replication lag. This lag means that some recently committed transactions may be lost during an unplanned failover. However, asynchronous replication has minimal impact on write performance and works well across high-latency WAN links for disaster recovery replicas.
Semi-synchronous replication, available in MySQL 5.5+ and PostgreSQL, provides a middle ground by waiting for the replica to acknowledge receipt of the transaction log before confirming the commit, without waiting for the replica to apply the changes. This guarantees that committed transactions exist on at least two servers while adding less latency than full synchronous replication. Evaluate each replication mode against your RPO and RTO requirements to select the optimal strategy.