hadoop-common-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Hadoop Wiki] Update of "ZooKeeper/FAQ" by PatrickHunt
Date Thu, 21 Jan 2010 18:29:23 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Hadoop Wiki" for change notification.

The "ZooKeeper/FAQ" page has been changed by PatrickHunt.


  When a ZooKeeper server generates the change events, it knows exactly what the change is.
In our initial implementation of ZooKeeper we returned this information with the change event,
but it turned out that it was impossible to use correctly. There may be a correct way to use
it, but we have never seen a case of correct usage. The problem is that watches are used to
find out about the latest change. (Otherwise, you would just do periodic gets.) The thing
that most programmers seem to miss, when they ask for this feature, is that watches are one
time triggers. Observe the following case of data change: a process does a getData on "/a"
with watch set to true and gets "v1", another process changes "/a" to "v2" and shortly there
after changes "/a" to "v3". The first process would see that "/a" was changed to "v2", but
wouldn't know that "/a" is now "/v3".
+ <<BR>>
+ <<Anchor(6)>>
+ '''6. [[#6|What are the options/process for upgrading ZooKeeper code?]]'''
+ There are two primary ways of doing this; 1) full restart or 2) rolling restart.
+ In the full restart case you can stage your updated code/configuration/etc..., stop all
of the servers in the ensemble, switch code/configuration, and restart the ZooKeeper ensemble.
If you do this programmatically (scripts typically, ie not by hand) the restart can be done
on order of seconds. As a result the clients will lose connectivity to the ZooKeeper cluster
during this time, however it looks to the clients just like a network partition. All existing
client sessions are maintained and re-established as soon as the ZooKeeper ensemble comes
back up. Obviously one drawback to this approach is that if you encounter any issues (it's
always a good idea to test/stage these changes on a test harness) the cluster may be down
for longer than expected.
+ The second option, preferable for many users, is to do a "rolling restart". In this case
you upgrade one server in the ZooKeeper ensemble at a time; bring down the server, upgrade
the code/configuration/etc..., then restart the server. The server will automatically rejoin
the quorum, update it's internal state with the current ZK leader, and begin serving client
sessions. As a result of doing a rolling restart, rather than a full restart, the administrator
can monitor the ensemble as the upgrade progresses, perhaps rolling back if any issues are

View raw message