[
https://issues.apache.org/jira/browse/CASSANDRA-45?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Eisenberg updated CASSANDRA-45:
-------------------------------------
Description:
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
was:
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.
Opening ticket for discussion.
Per Neophytos: distributed locks for multi-row puts
> 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.
