Database Replication

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
                       \--> replica2

If 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

• Database backup
• Eventual consistency
• Database sharding
• Load balancer

यह पेज सामान्य जानकारी है, जिसे हमारी संपादकीय टीम ने लिखा है और दस्तावेज़ीकरण बदलने पर अपडेट किया जाता है। सर्वर और प्रदाता अलग-अलग होते हैं, इसलिए बदलाव पहले सुरक्षित तरीके से जाँचें। देखें: संपादकीय नीति और अस्वीकरण.