cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "sankalp kohli (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-6246) EPaxos
Date Tue, 11 Nov 2014 20:52:35 GMT


sankalp kohli commented on CASSANDRA-6246:

One of the features we keep hearing from people moving from RDMS background is replicated
log style replication. This provides timeline consistency when you do the reads say in other
DC after a DC failure. Currently in C*, say you did 3 writes A,B and C. Here say B could not
be replicated to other DC. Now after failover, you will be reading A and C and not B. 

This breaks a lot of things for some applications. 

One of the advantages of epaxos is that it orders all writes on all machines. If all writes
are done via epaxos, I think it provide the above timeline consistency. 

So apart from epaxos being fast, I think this is a very important feature we get with it.

What do you think [~bdeggleston] 

> EPaxos
> ------
>                 Key: CASSANDRA-6246
>                 URL:
>             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:
> However, there is substantial additional complexity involved if we choose to implement

This message was sent by Atlassian JIRA

View raw message