Database Replication Strategies

A single database server is a single point of failure.If it goes down, your app stops.Replication creates copies of your data on multiple servers to ensure availability and improved performance.

Master - Slave(Primary - Replica)

The most common pattern.

• ** The Master ** handles all Writes(INSERT, UPDATE, DELETE) and replicates logs to slaves.
• ** The Slaves ** handles Read queries(SELECT).
• ** Pros:** Easy to scale reads.Just add more slaves.
• ** Cons:** Writes are still limited to the capacity of the single Master.Slave lag(delay in data syncing) can cause users to see outdated data immediately after an update.

Master - Master(Multi - Primary)

Two or more servers accept writes and sync with each other.

• ** Pros:** High write availability.If one master dies, writes continue on the other.
• ** Cons:** Complex conflict resolution.What if two users update the same row on different servers at the exact same millisecond ? Requires careful application design to avoid unique key collisions.

Synchronous vs.Asynchronous

• ** Asynchronous(Default):** Master writes to disk, tells client "Success", then sends data to slave.Fast, but if Master crashes before sending, data is lost.
• ** Synchronous:** Master sends to Slave, waits for Slave to confirm, THEN tells client "Success".Zero data loss, but significantly slower performance(latency of the network is added to every write).

Semi - Synchronous

A middle ground.The Master waits for * at least one * slave to acknowledge receipt before confirming success.This balances performance with data safety.