[
https://issues.apache.org/jira/browse/CASSANDRA-6246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14266223#comment-14266223
]
Blake Eggleston edited comment on CASSANDRA-6246 at 1/6/15 3:11 PM:
--------------------------------------------------------------------
By using the existing epaxos ordering constraints. Incrementing the epoch is
done by an instance which takes all unacknowledged instances as dependencies
for the token range it's incrementing the epoch for. The epoch can only be
incremented if all previous instances have also been executed.
I pushed up some commits that add the epoch functionality yesterday if you'd
like to take a look:
https://github.com/bdeggleston/cassandra/tree/CASSANDRA-6246
was (Author: bdeggleston):
By using the existing epaxos ordering constraints. Incrementing the epoch is
done by an instance which takes all unacknowledged instances as dependencies
for the token range it's incrementing the epoch for. The epoch can only be
incremented if all previous instances have also been executed.
> EPaxos
> ------
>
> Key: CASSANDRA-6246
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6246
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Reporter: Jonathan Ellis
> Assignee: Blake Eggleston
> Priority: Minor
>
> One reason we haven't optimized our Paxos implementation with Multi-paxos is
> that Multi-paxos requires leader election and hence, a period of
> unavailability when the leader dies.
> EPaxos is a Paxos variant that requires (1) less messages than multi-paxos,
> (2) is particularly useful across multiple datacenters, and (3) allows any
> node to act as coordinator:
> http://sigops.org/sosp/sosp13/papers/p358-moraru.pdf
> However, there is substantial additional complexity involved if we choose to
> implement it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
