Replication

Master-slave replication copies data from one primary to multiple secondaries.

How Master-Slave Works

Write Path:
Client → Master (write)

Read Path:
Client → Slave (read)

Replication:
Master → Slave 1 (async/semi-sync)
Master → Slave 2 (async/semi-sync)
Master → Slave 3 (async/semi-sync)

Master-Slave Architecture

                    ┌─────────────┐
                    │   Master    │
                    │   (write)   │
                    └──────┬──────
                           │
                   Replication
           ┌───────────────┼───────────────┐
           │               │               │
    ┌──────▼──┐     ┌──────▼──┐     ┌──────▼──┐
    │ Slave 1 │     │ Slave 2 │     │ Slave 3 │
    │ (read)  │     │ (read)  │     │ (read)  │
    └─────────┘     └─────────┘     └─────────┘

Replication Types

Type	Description	Consistency	Performance
Synchronous	Wait for all slaves	Strong	Slower
Asynchronous	Don't wait	Eventual	Faster
Semi-sync	Wait for 1 slave	Medium	Medium

Master-Slave Benefits

1. Read Scaling
   - Multiple slaves handle reads
   - Master focuses on writes

2. High Availability
   - Slave promotes to master on failure
   - Reduced downtime

3. Geographic Distribution
   - Slaves near users
   - Low-latency reads

4. Backup
   - Slaves for backup without affecting master

Master-Slave Challenges

1. Replication Lag
   - Async: slaves may have stale data
   - Read-after-write inconsistency

2. Single Write Point
   - Master is bottleneck for writes
   - No write scaling

3. Failover Complexity
   - Promoting slave to master
   - Reconfiguring other slaves

4. Data Consistency
   - Async replication can lose data
   - Master crash before replication

Master-master replication allows writes to multiple masters.

How Master-Master Works

Both masters accept writes:

Master 1 ←───Replication───→ Master 2
   │                            │
   └────────── Replication ─────┘

Client writes to either master
Changes replicate to both

Master-Master Architecture

           ┌─────────────┐
           │   Client    │
           └──────┬──────
                  │
         ┌────────┴────────┐
         │                 │
    ┌────▼────┐      ┌────▼────┐
    │ Master 1│←────→│ Master 2│
    │ (read/write)│  │ (read/write)│
    └────┬────┘      └────┬────┘
         │                │
    ┌────▼──┐        ┌────▼──┐
    │ Slave │        │ Slave │
    └───────┘        └───────┘

Master-Master Benefits

1. Write Scaling
   - Writes distributed across masters
   - Higher write throughput

2. High Availability
   - Either master can serve
   - No single point of failure

3. Geographic Distribution
   - Masters in different regions
   - Low-latency writes

Master-Master Challenges

1. Conflict Resolution
   - Same row updated on both masters
   - Which write wins?
   - Last-write-wins, merge, or reject

2. Complexity
   - More complex than master-slave
   - Harder to debug

3. Consistency
   - Eventual consistency required
   - Conflicts may occur

4. ID Generation
   - Auto-increment IDs conflict
   - Use UUIDs or distributed ID generators

Conflict Resolution Strategies

1. Last-Write-Wins (LWW)
   - Timestamp-based
   - Simple but may lose data

2. Merge
   - Combine changes
   - Application-specific logic

3. Reject
   - Reject conflicting writes
   - Require user intervention

4. CRDTs
   - Conflict-free replicated data types
   - Automatic merge

When to Use Master-Master

Use when:
- Need write scaling
- Multi-region active-active
- High availability critical
- Can handle eventual consistency

Avoid when:
- Strong consistency needed
- Simple architecture preferred
- Low write volume

Replication lag is the delay between master and slave data.

What is Replication Lag

Master: Write X = 1 at T=0
Slave: Receives X = 1 at T=100ms

Lag: 100ms

During this time:
- Master has X = 1
- Slave has X = 0
- Reads from slave return stale data

Measuring Replication Lag

-- PostgreSQL
SELECT now() - pg_last_xact_replay_timestamp() AS lag;

-- MySQL
SHOW SLAVE STATUS\\G
-- Seconds_Behind_Master: 5

-- MongoDB
rs.printReplicationInfo()
rs.printSecondaryReplicationInfo()

Lag Impact

Scenario: User updates profile, immediately views

1. User updates profile → Master
2. User views profile → Slave (lag)
3. Slave returns OLD data
4. User sees stale profile

Problem: Read-after-write inconsistency

Reducing Replication Lag

1. Optimize Replication
   - Use semi-synchronous
   - Optimize network
   - Reduce transaction size

2. Application-Level Solutions
   - Read-after-write consistency
   - Route reads to master after write
   - Use consistency levels

3. Monitor and Alert
   - Set lag thresholds
   - Alert when lag exceeds threshold
   - Route reads to master when lag high

Read-After-Write Consistency

Solution: Route reads to master after write

1. User writes to master
2. Subsequent reads go to master (for N seconds)
3. After N seconds, reads can go to slave

Implementation:
- Set flag after write
- Check flag for reads
- Clear flag after timeout

Replication Lag Best Practices

1. Monitor lag continuously: Set up alerts
2. Set acceptable lag threshold: Define SLA
3. Implement read-after-write: For consistency
4. Use semi-sync when needed: Balance consistency/performance
5. Test failover with lag: Ensure data consistency