Zookeeper hard
ZooKeeper utilizes 'Fuzzy Snapshots' to avoid locking the Znode tree during backups. How does the system handle data inconstancies that occur when a node is modified *while* a snapshot is being written to disk?
- A By pausing the Leader node's ZAB pipeline for the entire duration of the disk I/O operation.
- B By utilizing a filesystem-level Copy-on-Write (CoW) mechanism to isolate the in-memory heap.
- C By replaying the Transaction Log (WAL) starting from the point *before* the snapshot began to reach a consistent, globally ordered state.
- D By forcing the client to verify the cryptographic hash of the Znode metadata before every read request following a snapshot.
Answer: C. By replaying the Transaction Log (WAL) starting from the point *before* the snapshot began to reach a consistent, globally ordered state.
Locking the tree would halt the cluster. By combining a potentially inconsistent (fuzzy) disk dump with a strictly ordered WAL (Write Ahead Log), ZK reconstructs the precise state without downtime.
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?