Zookeeper hard
A Follower node rejoins the ensemble. It contains an uncommitted transaction log entry with `ZXID: 500`. The current authoritative Leader only has reached `ZXID: 499`. How does ZooKeeper resolve this discrepancy?
- A The Leader issues a DIFF instruction and appends its own history to the Follower's existing log.
- B The Follower is discarded and forced to perform a full SNAP (Snapshot) synchronization from the Leader's RAM.
- C The Leader issues a TRUNC instruction, forcing the Follower to delete the uncommitted Transaction 500 and align with the cluster's majority history.
- D The system automatically performs a three-way merge using the client session ID as the tie-breaker for the conflicting ZXIDs.
Answer: C. The Leader issues a TRUNC instruction, forcing the Follower to delete the uncommitted Transaction 500 and align with the cluster's majority history.
The Follower has divergent history. Since the entry 500 was never committed by a quorum, it is invalid. The Follower must cut its log back to the common ancestor point.
One system design question a day, with spaced repetition so the ones you miss come back.
Get the appRelated questions
- What is the primary technical function of a ZooKeeper 'Watch'?
- A system administrator increases `jute.maxbuffer` to 5MB on every ZooKeeper server to store large configuration objects. However, write operations larger than 1MB still fail. What is the most likely cause?
- By default, `forceSync` is enabled. If you disable it, what trade-off are you making?
- If the specific ZooKeeper node a client is connected to crashes, what should the client do?
- Which cluster configuration has *worse* availability: A 3-node cluster or a 4-node cluster? (Assuming simple majority quorum)
- According to the CAP Theorem, how is ZooKeeper classified?