cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-5797) DC-local CAS
Date Wed, 24 Jul 2013 11:49:50 GMT

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

Sylvain Lebresne commented on CASSANDRA-5797:
---------------------------------------------

bq. Not sure what CQL syntax for this is. Is it protocol level the way CL is?

That's a good question and I'm not really sure what's the right answer.

I think it may make the most sense to make it protocol level because of reads.  For CAS writes,
we do have a CQL syntax for it, so we could extends it with say:
{noformat}
UPDATE foo SET v1 = 2, v2 = 3 WHERE k = 1 IF v1 = 1 AND v2 = 1 IN LOCAL DC
{noformat}
But for reads, we don't have any syntax, the consistency level (SERIAL) is the only thing
that makes a read go through paxos, so I'm afraid adding some CQL syntax in that case would
be confusing.

But even making it protocol level is not that easy. For thrift, on the read side, the only
way I can see us supporting this DC-local CAS would be add a LOCAL_SERIAL consistency level
(short of duplicating all read methods for CAS reads that is). But that doesn't really work
for writes since the consistency level for writes is really the consistency of the paxos learn/commit
phase.

One option (the best I can come up with so far) would be to add the LOCAL_SERIAL consistency
level, and then to change CAS write to take 2 CL: the first one would be for the commit (learn)
phase (as we have now, but we would refuse CL.SERIAL and CL.LOCAL_SERIAL in that case) and
a 2nd CL that would control the "Paxos consistency" (and for that one, only CL.SERIAL or CL.LOCAL_SERIAL
would be valid). It's not perfect however because the one thing you can't properly express
is the ability to do CL.SERIAL for paxos but don't wait on any node for the learn phase. Unless
we make CL.ANY for the "commit consistency" mean that, but that's a slight stretch.

In any case, we should probably make it sure to shove that in 2.0.0 because I don't want to
change the thrift API nor break the native protocol in 2.0.1.

Any better idea?

                
> DC-local CAS
> ------------
>
>                 Key: CASSANDRA-5797
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-5797
>             Project: Cassandra
>          Issue Type: Bug
>          Components: API
>    Affects Versions: 2.0
>            Reporter: Jonathan Ellis
>            Assignee: Sylvain Lebresne
>            Priority: Minor
>             Fix For: 2.0.1
>
>
> For two-datacenter deployments where the second DC is strictly for disaster failover,
it would be useful to restrict CAS to a single DC to avoid cross-DC round trips.
> (This would require manually truncating {{system.paxos}} when failing over.)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message