[jira] Commented: (CASSANDRA-45) Integrate with ZooKeeper to enhance fault tolerance and coordination

["Jonathan Ellis (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CASSANDRA-45?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12695059#action_12695059 ] 

Jonathan Ellis commented on CASSANDRA-45:
-----------------------------------------

-1 on locks.  it's adding more complexity in an effort to make the system more consistent, which can only be really done if you are willing to give up availability, which we are not.

In my mind the place for zookeeper is for rare system-level events, e.g. load balancing or bootstrap, not to attempt to layer strong consistency on the client-facing API.

Avinash: "Options are either [eventual consistency or] strong consistency which is hard to get right in a distributed setting. If you do get it right then there is availability problem. All tools like read-repair etc help in achieving eventual consistency. So I guess it boils down to what you want from your app C or A."

Of course I don't want to put words into his mouth as to what he thinks about this specific proposal.

> Integrate with ZooKeeper to enhance fault tolerance and coordination
> --------------------------------------------------------------------
>
>                 Key: CASSANDRA-45
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-45
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Brett Eisenberg
>
> Per Avinash:
> (1) Store all configuration specific information in ZK for availability purposes. For eg. today we store the token info of a node in local disk. In production we lost that disk and with that the token info.
> (2) For storage load balance which does not exist today. I would like to have the notion of leader who would orchestrate a load balance strategy.
> (3) Distributed locks - suppose one of the replicas wanted to trigger a compaction process. Then we can prevent the other replicas to also initiate one so that we can get better read performance. 
> (4) There are operation stuff that needs to be set up when bootstrap of new nodes is in order. This intermediate state can be placed in ZK and then deleted on bootstrap completion. This way if the node handing of the data dies in between then it can continue from where it left off on re-start.
> additionally, configuration state data, cluster membership, and node visibility could be enhanced using ZK as well.
> Per Neophytos: distributed locks for multi-row puts

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.