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/GSoCReadOnlyMode" by Sergey Doroshenko
Date Thu, 06 May 2010 17:18:53 GMT
Dear Wiki user,

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

The "ZooKeeper/GSoCReadOnlyMode" page has been changed by Sergey Doroshenko.


New page:

When a !ZooKeeper server loses contact with over half of the other servers in an ensemble
('loses a quorum'), it stops responding to client requests. For some applications, it would
be beneficial if a server still responded to read requests when the quorum is lost, but caused
an error condition when a write request was attempted.

This project would implement a 'read-only' mode for !ZooKeeper servers that allowed read requests
to be served as long as the client can contact a server.


'''Detailed description'''

Currently when ZK looses a quorum, say 3 of 5 servers become dead, 2 others which are alive

 1. start throwing exceptions during leader election
 1. drop existing clients connections
 1. drop new clients should ones connect

-- and so and so in a loop, until quorum will be re-established.

Naive idea is to change current behaviour in the way that server doesn't drop clients when
partitioned (only informs them about partitioning), and only throw exceptions when client
is attempting a write. This is backwards incompatible change on how users currently manage


My idea is to do the following:

 * Create "read-only" Zookeeper client -- either by adding read-only mode in current !ZooKeeper
class (and passing "mode" parameter in ctor), or by creating separate class (possibly by extending
current !ZooKeeper to allow transparent usage by ZK users).
 * Make server distinguish these 2 types of clients. For old ones behaviour remains the same,
which eliminates backwards incompatibility. <<BR>>For new "read-only" clients
server actions are these: <<BR>>
  * when we are in quorum, allow all operations, as if the client is the normal one
  * when partitioning occurs, inform clients about state change
  * when we are partitioned, allow only read operations, answer with exception to writes

Benefits of this approach: transparent usage of a new client, backwards compatible.

Drawbacks: more coupling between server and client.


'''Related links'''

Jira ticket: [[https://issues.apache.org/jira/browse/ZOOKEEPER-704|ZOOKEEPER-704]]

My GSoC [[http://docs.google.com/View?id=dghqvqdd_51ffvhcsdb|proposal]]

View raw message