DBMS Notes
Replication is the process of maintaining identical copies of data — either complete relations or fragments — at multiple sites in a distributed database...
Definition
Replication is the process of maintaining identical copies of data — either complete relations or fragments — at multiple sites in a distributed database system. When data is replicated, an update to any copy must eventually be reflected in all other copies to maintain consistency across the system.
Replication is one of the fundamental techniques in distributed databases, alongside fragmentation. While fragmentation divides data to distribute the workload, replication duplicates data to improve availability and performance. These two techniques are often used together — a relation might be fragmented first, and then each fragment is replicated at multiple sites.
Replication Models
Synchronous Replication (Eager)
In synchronous replication, all replicas are updated as part of the same transaction. The transaction does not commit until every site confirms the update.
| Transaction | UPDATE Employee SET salary = 70000 WHERE emp_id = 101 |
| 2. Send update to Site B | wait for acknowledgment |
| 3. Send update to Site C | wait for acknowledgment |
| 4. ALL sites confirmed | COMMIT transaction |
| 5. Any site fails to confirm | ABORT entire transaction |
| - Strong consistency | all replicas always identical |
| - High latency | transaction speed limited by slowest site |
| - Lower availability | if any replica site is down, transaction cannot commit |
Synchronous replication is used when absolute consistency is required — financial systems, inventory management, or any application where reading stale data could cause serious errors.
Asynchronous Replication (Lazy)
In asynchronous replication, the transaction commits at the primary site immediately. Changes are propagated to replicas in the background, with some delay.
| Transaction | UPDATE Employee SET salary = 70000 WHERE emp_id = 101 |
| 1. Update at primary site | COMMIT immediately |
| 2. Background process sends changes to replicas (delay | milliseconds to minutes) |
| - Eventual consistency | replicas temporarily stale but converge |
| - Low latency | commits as fast as single-site transaction |
| - High availability | continues operating even if replica sites are down |
| - Conflict risk | if multiple sites accept writes, conflicting updates possible |
Asynchronous replication is used in read-heavy applications where slight staleness is acceptable — content delivery, social media feeds, product catalogs, and analytics databases.
Replication Topologies
Master-Slave (Primary-Replica)
Architecture
Primary (Master) ──writes──► Primary storage
│
├──replicates──► Replica 1 (read-only)
├──replicates──► Replica 2 (read-only)
└──replicates──► Replica 3 (read-only)
Rules
- ALL writes go to the primary
- Replicas serve read queries only
- If primary fails, one replica is promoted to new primary (failover)
Used in: MySQL replication, PostgreSQL streaming replication, Amazon RDS read replicas
Multi-Master
Architecture
Site A ◄──synchronizes──► Site B
│ │
└───── synchronizes ──────┘
Site C
Rules
- Any site can accept both reads AND writes
- Changes must be propagated and conflicts resolved
- Conflict resolution: last-writer-wins, application-defined, or merge
Used in: CouchDB, MySQL Group Replication, Active Directory
Peer-to-Peer
All nodes are equal — there is no designated primary. Each node can independently accept reads and writes and propagates changes to all peers. This model provides the highest availability but requires sophisticated conflict detection and resolution mechanisms.
Consistency Models in Replication
| Model | Description | Guarantee |
|---|---|---|
| Strong Consistency | Read always returns most recent write | All replicas identical at all times |
| Eventual Consistency | Replicas converge over time | Reads may return stale data temporarily |
| Read-Your-Writes | You see your own updates immediately | Other users may see stale data |
| Monotonic Reads | Never see older data after seeing newer | Progressive freshness guaranteed |
| Causal Consistency | Causally related writes seen in order | Concurrent writes may appear in any order |
Trade-offs: The CAP Theorem Connection
The CAP theorem states that a distributed system can provide at most two of three guarantees simultaneously:
- Consistency: Every read receives the most recent write
- Availability: Every request receives a response (not an error)
- Partition Tolerance: System continues despite network partitions
Since network partitions are inevitable in distributed systems, the practical choice is between consistency (CP systems) and availability (AP systems) during partitions.
CP Systems (consistency over availability)
During network partition → reject writes to maintain consistency
Examples: HBase, MongoDB (in certain configurations), traditional RDBMS
AP Systems (availability over consistency)
During network partition → accept writes, resolve conflicts later
Examples: Cassandra, DynamoDB, CouchDB
Replication Control Mechanisms
Update Propagation Strategies
| Strategy | How Updates Spread | Trade-off |
|---|---|---|
| Immediate | Update all replicas within the transaction | Highest consistency, highest cost |
| Deferred | Propagate after transaction commits | Lower latency, temporary inconsistency |
| Periodic | Batch updates at regular intervals | Lowest network cost, highest staleness |
Conflict Detection and Resolution
When multiple sites can accept writes (multi-master), conflicts may occur:
Conflict Example
Site A: UPDATE Product SET price = 100 WHERE id = 5 (at time T1)
Site B: UPDATE Product SET price = 120 WHERE id = 5 (at time T1)
Resolution strategies
1. Last-Writer-Wins: Use timestamp, latest write survives
2. Application-defined: Custom merge logic (e.g., take higher price)
3. Conflict flagging: Mark record as conflicted, require manual resolution
Key Points to Remember
- Replication improves availability and read performance but complicates write operations
- Synchronous replication guarantees consistency but reduces performance and availability
- Asynchronous replication provides better performance but only eventual consistency
- Master-slave is simplest (one write point); multi-master is complex (conflict resolution needed)
- The CAP theorem fundamentally limits what replication can achieve during network failures
- Most real-world systems use asynchronous replication with eventual consistency for scalability
Exam Focus
Revise definitions, diagrams, examples, and short-answer points for Replication in Distributed Databases.
Interview Use
Prepare one clear explanation, one practical example, and one common mistake for this Database Management Systems (DBMS) topic.
Search Terms
dbms, database management systems (dbms), unit, replication, replication in distributed databases
Related Database Management Systems (DBMS) Topics