This is my personal learning notes from reading <> Chapter 5.

What is replication?

Replication means keeping a copy of the exact same data on multiple places that are connected via network.

The purpose of replication:

Fault tolerance: If part of the machine failed, other machines can still work.
Scale reads: Reads can be balanced to all replications to achieve read volume scaling, also you can select the closest replications as possible to serve reads.

What makes replication difficult?

If all machines store the same static data that never change, then replication is just a one hot effort, but what if the data is constantly changing?

How to make sure changes applied to all replicas?
How to handle replication failures?

To answer these questions, you’d also determine your target first. replication can happen for a database, API server, cache etc.

Solution

Leaders/followers Replication Architecture

Write requests go to leader only, leader responsible for broadcasting new data to all replicas. Traditional relational database uses this way.

Replication log or write ahead logs: The media of changed data capture.
Leader election: The mechanism to ensure leader always exists, leader exists to coordinate the replication. Algorithms of leader consensus: ZAB, RAFT, PAXOS.
Asynchronous VS Synchronous replication: The mechanism of applying data changes
Eventual Consistency: The promise/goal of distributed replication process.
Distributed transaction:
Conflict resolution: The problem arise during concurrent data update in a distributed environment, Conflict must be resolved in a way to ensure eventual consistency. Algorithms include: Last Write Win, Operational transformation, CRDT etc.
Multi-leader clusters: say we have two data centres, each data centre has a cluster with leader/followers setup, and we need to sync data between these two data centres.

Non-Leader Replication Architecture

Read/Write requests go to all replicas at the same time, Amazon DynamoDB and Cassandra belong to this category.

Since all replicas are treated the same, to improve efficiency, quorum consistency for read/write is usually implemented, this means a read/write request is succeed only if w out of n total replicas succeed.

Then for the failed nodes, they need to catch up:

Read repair: Repair missing data upon client requests.
Anti-entropy process: backend job to periodically check lag behind data and repair.

The real implementation is way more complicated as you also need to consider what if the defined quorum can’t be achieved, a hinted handoff solution can be adopted.