Replication
Master-slave, multi-master, read replicas, replication lag, conflict resolution
Database replication asynchronously or synchronously copies data from a primary (leader) to one or more replicas (followers) to achieve read scalability, geographic distribution, and high availability. The core trade-off is replication lag: asynchronous replication is faster but allows replicas to serve stale data; synchronous replication guarantees consistency but increases write latency and reduces availability if a replica is slow or unreachable. Multi-master replication allows writes on multiple nodes, requiring conflict detection and resolution strategies.
Key Points
- Asynchronous replication (MySQL binlog, PostgreSQL streaming): primary commits before replica acknowledges; replication lag can range from milliseconds to minutes under load.
- Synchronous replication (PostgreSQL synchronous_commit=on): primary waits for at least one replica to flush WAL before returning; adds ~RTT latency to each write but guarantees no data loss on primary failure.
- Read replicas absorb 60–80% of read traffic in typical OLTP systems; route SELECT queries to replicas, INSERT/UPDATE/DELETE to primary via application-level or proxy-level routing (ProxySQL, pgBouncer).
- Replication lag monitoring: track seconds_behind_master (MySQL) or pg_stat_replication.replay_lag (PostgreSQL); alert at >30 seconds for most OLTP applications.
- Multi-master (active-active): Galera Cluster (PXC), CockroachDB, Spanner allow writes to any node; conflicts are resolved by last-writer-wins or by aborting one transaction.
- Conflict-free Replicated Data Types (CRDTs) enable multi-master replication without conflicts for specific data types: counters, sets, registers — used in Riak and DynamoDB DAX.
- Failover with auto-promotion: Patroni (PostgreSQL), MHA (MySQL), Orchestrator manage leader election using distributed consensus (etcd, ZooKeeper) to avoid split-brain.
- Logical replication (PostgreSQL logical decoding, MySQL row-based binlog) enables selective table replication, cross-version replication, and CDC pipelines to Kafka via Debezium.
Real-World Example
GitHub uses MySQL with Orchestrator for automatic failover; they maintain 3 replicas per primary and promote the most up-to-date replica during failover, tolerating up to 30 seconds of lag. Cloudflare replicates their core PostgreSQL database synchronously within a region (sub-5ms RTT) and asynchronously across regions for disaster recovery.