Database Replication
The practice of sharing information across multiple database servers to ensure data consistency and availability.
Detailed Explanation
In a 'Leader-Follower' setup, all writes go to the leader, and the changes are copied to the followers. This allows you to scale read traffic (followers) and provides a backup if the leader fails (high availability). In 'Multi-Leader' or 'Leaderless' setups, writes can happen on multiple nodes, but this introduces complex conflict resolution challenges.
Quick Summary
Replication keeps copies of your database on additional servers, for high availability, disaster recovery, read scaling, and geographic locality. Most production systems run it; the modes and tradeoffs vary.
Key Takeaways
- Topologies: leader-follower (most common), multi-leader, leaderless (Dynamo-style).
- Synchronous replication = zero data loss, higher write latency. Asynchronous = fast writes, potential data loss on failover.
- Replication lag means "read your own writes" requires care, reading from a replica right after writing can return stale data.
- Replicas are not backups, a `DROP TABLE` on the leader replicates instantly.
- Geo-replication reduces read latency for global users but multiplies write latency unless you go multi-region carefully.
When to use it
- Read scaling for read-heavy workloads (analytics, dashboards, search-by-key APIs).
- Hot standby for fast failover when the primary dies.
- Cross-region replicas for disaster recovery and low-latency reads near users.
- Logical replication for streaming changes into a data warehouse or search index.
Common Mistakes
- Treating replicas as backups; they propagate destructive operations just as quickly as legitimate ones.
- Sending all reads to replicas without considering replication lag, recently-written data appears missing.
- No monitoring on replication lag, so split-brain or stalled replicas go unnoticed for hours.
- Multi-leader replication without conflict resolution policy, last-write-wins quietly loses data.
Database Replication, Frequently Asked
Can I run a read replica as my backup?
Not by itself. Replicas mirror every operation including mistakes. Take separate logical or snapshot backups with retention, and test restores periodically. Replicas + backups, not replicas instead of backups.
Sync or async replication?
Async by default for performance. Use sync (or semi-sync) when zero data loss is required, financial systems, regulated workloads. Be aware of the latency cost and the risk of writes blocking if a sync replica falls behind.