Master-Backup Replication

Overview

• Architecture: One master node, multiple backup/replica nodes
• Write Direction: Unidirectional from master to replicas
• Simplicity: Easiest replication pattern, conflict-free
• Single Write Source: All writes through master only

Architecture Components

Master Node (Primary/Leader)

• Writes: Accepts all INSERT, UPDATE, DELETE, DDL operations
• Reads: Can serve read queries
• Replication Log: Generates change log for replicas

Backup Nodes (Replicas/Standby)

• Read-Only: Serve read queries, no direct writes
• Replication: Apply changes from master
• Lag: May be behind master (eventual consistency)

Replication Methods

Synchronous Replication

• Process: Master waits for replica confirmation before commit
• Trade-off: No acked-commit loss on failover, but higher write latency. Replica reads can still be stale unless the master waits for the replica to apply the change (Postgres synchronous_commit = remote_apply)
• Use Case: Critical data requiring consistency

Asynchronous Replication

• Process: Master commits immediately, replicas catch up later
• Trade-off: Low latency but potential data loss on failure
• Use Case: High performance requirements

Semi-Synchronous Replication

• Process: Wait for at least one replica confirmation
• Trade-off: Balanced consistency and performance
• Use Case: A MySQL feature (Postgres has no semi-sync mode; it uses sync with ANY 1 (...) quorum or async)

Advantages

• Simplicity: Easy setup, clear roles, simple operations
• Read Scalability: Distribute reads across replicas, offload master
• Geographic Distribution: Place replicas near users for low latency
• High Availability: Failover to replica, disaster recovery
• Workload Isolation: Analytics on replicas, OLTP on master

Disadvantages

• Write Bottleneck: Single master limits write scalability
• Replication Lag: Replicas may show stale data
• Failover Complexity: Manual intervention, potential data loss, split-brain risk
• Single Point of Failure: Master failure stops all writes

Use Cases

Read-Heavy Applications

• Examples: Content websites, news portals, blogs
• Benefit: Distribute reads across replicas

Reporting and Analytics

• Examples: Business intelligence, data warehousing
• Benefit: Heavy queries on replicas without impacting master

Geographic Distribution

• Examples: Global applications
• Benefit: Low-latency reads from nearby replicas

Disaster Recovery

• Examples: Mission-critical databases
• Benefit: Live standby replicas for quick recovery

Failover Strategies

Manual Failover

• Trade-off: Full control but higher downtime

Automatic Failover

• Process: Detect failure, select most current replica, promote to master
• Trade-off: Faster recovery but split-brain risk
• Tools: Consensus algorithms (Raft, Paxos), monitoring

Configuration Considerations

Replication Mode

• Synchronous: Critical data, tolerate latency
• Asynchronous: High performance, tolerate lag
• Semi-Synchronous: Balanced requirements

Number of Replicas

• Factors: Read load, geographic needs, redundancy requirements
• Minimum: 2 replicas for high availability

Network Topology

• Same Data Center: Low latency, single point of failure
• Different Data Centers: High availability, higher latency
• Cloud Regions: Geographic distribution

Monitoring Metrics

• Replication Lag: Time/bytes behind master
• Replica Health: Connection status, errors
• Write Throughput: Master capacity usage
• Read Distribution: Load across replicas

Best Practices

Application Design

• Read Routing: Direct reads to replicas, writes to master
• Lag Tolerance: Design for eventual consistency
• Retry Logic: Handle transient issues

Configuration

• Mode Selection: Choose based on consistency vs performance needs
• Connection Pooling: Separate pools for master/replicas
• Monitoring: Track lag, health, and throughput

Operations

• Regular Backups: Don’t rely solely on replication
• Failover Testing: Test procedures regularly
• Documentation: Document topology and procedures

Common Implementations

MySQL Master-Slave

• Binary log replication, GTID tracking

PostgreSQL Streaming Replication

• WAL streaming, hot standby, replication slots

MongoDB Replica Sets

• Primary/secondary nodes, automatic failover

Summary

• Pattern: Single master for writes, multiple replicas for reads
• Strengths: Simple, conflict-free, good read scalability
• Weaknesses: Single write point, replication lag, limited write scaling
• Best For: Read-heavy workloads, geographic distribution, disaster recovery
• Key Trade-off: Consistency vs performance (sync vs async)