Database replication continuously copies changes from a primary database server to one or more replicas. Replicas can serve reads or take over if the primary fails.
Why it matters
Replication provides redundancy, so a hardware failure does not mean data loss or a long outage, and it lets you spread read traffic across several servers. It may be synchronous, where a commit waits for the replica, or asynchronous, where the replica may lag slightly. Lag is the key trade-off: reading from a replica can return slightly old data.
Example
app writes -> primary (db1)
app reads -> replica1, replica2
primary --stream changes--> replica1
\--> replica2If db1 fails, a replica is promoted to become the new primary.
Common mistakes
- Treating replication as a backup. A bad delete or corruption replicates to every copy.
- Reading your own just-written data from a lagging replica and seeing it missing.
- Never testing failover, so the first real failure is also the first rehearsal.
Related
Get notified when this term updates
Plus occasional practical tips on uptime and monitoring, nothing else. Unsubscribe anytime.
This page is general information written by our editorial team and updated when documentation changes. Servers and providers differ, so test changes safely first. See our editorial policy and disclaimer.