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, 30 Sep 2014 00:22:34 GMT


sankalp kohli commented on CASSANDRA-6246:

Inconsistencies can be introduced by machines being down or network partitioned for longer
than we replay missed updates to it. Currently for normal writes, hint is for 1 hour. If you
bring in a machine after 1 hour, you run a repair. But repair won't help here since it takes
time to run the repair and new LWTs will come and will see a different view of the data and
won't apply. 

"However, like I mentioned in my comment yesterday, I think we can work out a way to detect
and correct this."

"Assuming each instance is an average of ~170 bytes (uncompressed), sustained 1000 instances
per second for 3 hours would keep ~1.8GB of data around."
Here instance includes the condition and update. Update could be quite big and keeping it
around could be problematic. 

> 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