• See http://techblog.netﬂix.com/2011/07/
A tool that randomly disables our production instances to make sure we can
survive common types of failure without any customer impact.
• Completely unmanned
• Bringing up a new ensemble should be
Each Exhibitor instance monitors the
ZooKeeper server running on the same
server. If ZooKeeper is not running, Exhibitor
will write the zoo.cfg ﬁle, etc. and start it. If
ZooKeeper crashes for some reason,
Exhibitor will restart it.
In versions prior to ZooKeeper 3.4.x, log ﬁle
maintenance is necessary. Exhibitor will
periodically do this maintenance.
Backups in a ZooKeeper ensemble are more complicated
than for a traditional data store (e.g. aRDBMS). Generally,
most of the data in ZooKeeper is ephemeral. It would be
harmful to blindly restore an entire ZooKeeper data set.
What is needed is selective restoration to prevent accidental
damage to a subset of the data set. Exhibitor enables this.
Exhibitor will periodically backup the ZooKeeper transaction
ﬁles. Once backed up, you can index any of these transaction
ﬁles. Once indexed, you can search for individual transactions
and “replay” them to restore a given ZNode to ZooKeeper.
Exhibitor presents a single console for your
entire ZooKeeper ensemble. Conﬁguration
changes made in Exhibitor will be applied to
the entire ensemble.
Exhibitor can update the servers in the
ensemble in a rolling fashion so that the
ZooKeeper ensemble can stay up and in
quorum while the changes are being made.
Exhibitor provides a graphical tree view of
the ZooKeeper ZNode hierarchy.
When enabled, Exhibitor can create/update/
delete nodes in the ZooKeeper hierarchy.
Exhibitor and Curator (Cur/Ex!) can be
conﬁgured to work together so that Curator
instances are updated for changes in the
Exhibitor Exhibitor Exhibitor
A B ...
Round Robin - periodic query for servers list