cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sandeep Tata (JIRA)" <j...@apache.org>
Subject [jira] Commented: (CASSANDRA-45) Integrate with ZooKeeper to enhance fault tolerance and coordination
Date Thu, 02 Apr 2009 17:58:12 GMT

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

Sandeep Tata commented on CASSANDRA-45:
---------------------------------------

I agree with a majority of the goals. 

> (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
0 : I don't see big problems except we'll need to make sure this doesn't adversely affect
the gossip protocol. If we're just using ZK to cache each node's token info separately, we're
simply using ZK as "backup" so it won't affect the  protocol at all. I'm not sure how useful
this is.

> (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.

+1 : Makes sense. Leader election for coordinating load balancing -- exactly what ZK was built
for.

> (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.
+1 : This is going to add some complexity, but I'm guessing this becomes critical when you
want to guarantee read performance in a production setting.

> (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.
0 : Not sure I know what "operation stuff" is yet. Not sure if there's any value to using
ZK as a backup log.

I'm fine with people layering stronger consistency on top of Cassandra where this layer sacrifices
some availability. If you want multi-row puts, you will give up availability under a bunch
of scenarios. That is fine so long as the implementation does not affect the performance of
the underlying eventually consistent system in any way. 

> 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.


Mime
View raw message