cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Blake Eggleston (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-6246) EPaxos
Date Fri, 27 Feb 2015 00:31:06 GMT

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

Blake Eggleston commented on CASSANDRA-6246:
--------------------------------------------

I just merged some commits into my CASSANDRA-6246 branch. This is the initial implementation
of the epoch, instance gc, streaming/repair, read repair, and failure recovery logic. I also
have a dtests fork that tests it here: https://github.com/bdeggleston/cassandra-dtest/tree/CASSANDRA-6246.

I still have some items I need to complete before submitting review, but nothing major (relative
to this stuff). Mostly cleaning up and refining things.

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

Mime
View raw message