Master-Slave replication is the foundational building block of database scaling. By dedicating one node to write commands and secondary nodes to read queries, we split the I/O bottleneck and gain system resilience.
Here is how data flows in a Master-Slave setup. Note that write requests go exclusively to the Master database, which asynchronously propagates changes to the Slaves, while read queries are load-balanced across the Slaves:
When database read/write request velocity is extremely high, a single server experiences heavy disk and socket I/O bottlenecks. Master-Slave splits this work: the Master server handles writing locks, while lightweight read-oriented secondary servers handle queries, preventing transaction starvation.
This setup is the physical implementation of CQRS (Command Query Responsibility Segregation). Write command queries (INSERT, UPDATE, DELETE) target the Master (command), and read queries (SELECT) target Slaves (query).
By offloading queries to multiple replicas, we ensure that if one replica fails, requests fail over to another replica. Furthermore, read queries are served locally near users (reducing round-trip latency) without taxing the transactional master.
Database replication handles transferring transaction logs from Master to Slaves. This runs in either synchronous (strong consistency but high write latency) or asynchronous (eventual consistency with replication lag) configuration.
Depending on your database requirements (e.g. banking transactions vs. social media feeds), you must configure replication carefully:
| Replication Type | How it Works | Pros | Cons | Typical Use Case |
|---|---|---|---|---|
| Synchronous | Master waits for confirmation from all (or a quorum of) slaves that the write log is written on their disk before acknowledging success to the client app. | Zero Replication Lag. Perfect data consistency across all nodes. | Slow write latency. If a single slave node blocks or crashes, all writes to the Master block as well. | Banking ledgers, financial accounts. |
| Asynchronous | Master writes data locally and immediately sends success acknowledgment to the app. Replicates logs to slaves in the background. | Fast writes (low latency). Master remains healthy even if slaves fail. | Replication lag occurs. For a few seconds, slaves contain stale data. Potential data loss if master crashes before logs sync. | Cab driver coordinates, social media posts, search indexes. |
Master-Slave replication is the foundational mechanism for Database Clustering.
In database clustering configurations (Active-Passive or Active-Active), a cluster manager checks node health. If the Master node suffers a physical disk failure, the clustering engine triggers an automatic failover election. One of the Slaves is promoted to Master to begin receiving write requests, ensuring high availability.
True clustering uses a load-balancing layer (like PgBouncer or HAProxy) that intercepts client calls. The clustering controller checks read loads on the Slave nodes and distributes incoming queries symmetrically, ensuring no single slave gets overwhelmed.