A replica is a server or system member that maintains a copy of data or state from a primary. In a primary–backup design, the primary orders writes and broadcasts updates, while replicas serve local reads. A replica can first receive a complete snapshot, then apply incremental changes. section 4.7 section 4.8
A practical primary–replica workflow is:
- Start the primary and accept writes there; broadcast each Put update to the replica set. section 4.8
- Let a replica join by sending its network address to the primary. section 4.8
- Send a snapshot when the replica joins, so its state matches the primary before incremental updates arrive. section 4.8
- Read locally from the replica after synchronization, while recognizing that the simple implementation does not describe durability or recovery guarantees. section 4.8
Viewstamped Replication extends the primary–backup model for fault-tolerant distributed systems. Replicas acknowledge requests, and the primary waits for a quorum before replying. If the primary fails, backups initiate a view change and deterministically select a new primary; view numbers act as logical clocks for cluster state. section 4.7
Replicated key–value store
A primary accepts PUT a 1 and PUT b 2. A newly started replica initially returns “Not found” for both keys. After JOIN localhost:8080, it receives a snapshot and returns a -> 1 and b -> 2. When the primary later stores c = 3, the replica can read c locally after receiving the broadcast update. section 4.8
Figure 4.8 Example of Viewstamped Replication normal operation message flow
Inspect the message flow for normal Viewstamped Replication operation. section 4.7
