[jira] [Commented] (CASSANDRA-5797) DC-local CAS
[
https://issues.apache.org/jira/browse/CASSANDRA-5797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13965394#comment-13965394
]
Oleg Poleshuk commented on CASSANDRA-5797:
--
Is there a way to change serial consistency level from CQL / Java driver?
http://stackoverflow.com/questions/22666911/cassandra-cql-consistency-during-cas-operations
> 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 beta 1
>Reporter: Jonathan Ellis
>Assignee: Sylvain Lebresne
>Priority: Minor
> Fix For: 2.0 rc1
>
> Attachments: 0001-Thrift-generated-files.txt,
> 0002-Add-LOCAL_SERIAL-CL.txt, 0003-CQL-and-native-protocol-changes.txt
>
>
> 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 was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CASSANDRA-5797) DC-local CAS
[
https://issues.apache.org/jira/browse/CASSANDRA-5797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13720883#comment-13720883
]
Aleksey Yeschenko commented on CASSANDRA-5797:
--
QueryOptions.Codec.encode() writes flags before writing the CL - should be
reversed. Otherwise LGTM.
> 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 beta 1
>Reporter: Jonathan Ellis
>Assignee: Sylvain Lebresne
>Priority: Minor
> Fix For: 2.0 rc1
>
> Attachments: 0001-Thrift-generated-files.txt,
> 0002-Add-LOCAL_SERIAL-CL.txt, 0003-CQL-and-native-protocol-changes.txt
>
>
> 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
[jira] [Commented] (CASSANDRA-5797) DC-local CAS
[
https://issues.apache.org/jira/browse/CASSANDRA-5797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13720820#comment-13720820
]
Jonathan Ellis commented on CASSANDRA-5797:
---
+1 (mostly looked at patch 2)
Nit: rename isSameDCThan to isSameDCAs, or maybe better sameDCPredicateFor
(since "is" implies it's doing a boolean evaluation)
> 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 beta 1
>Reporter: Jonathan Ellis
>Assignee: Sylvain Lebresne
>Priority: Minor
> Fix For: 2.0 rc1
>
> Attachments: 0001-Thrift-generated-files.txt,
> 0002-Add-LOCAL_SERIAL-CL.txt, 0003-CQL-and-native-protocol-changes.txt
>
>
> 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
[jira] [Commented] (CASSANDRA-5797) DC-local CAS
[
https://issues.apache.org/jira/browse/CASSANDRA-5797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13719041#comment-13719041
]
Jonathan Ellis commented on CASSANDRA-5797:
---
bq. The thing is that for reads, we must have SERIAL and LOCAL_SERIAL in CL if
we want thrift to support it. So once we have them in CL, is it really worth
adding a separate enum for the write case?
The problem is that none of {ANY, ONE, TWO, THREE, LOCAL_QUORUM, EACH_QUORUM}
are valid on writes, which isn't very clear if we reuse CL for everything.
Then again we ANY is not a valid CL for read, and EACH_QUORUM is not valid for
writes. I dunno.
> 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
[jira] [Commented] (CASSANDRA-5797) DC-local CAS
[
https://issues.apache.org/jira/browse/CASSANDRA-5797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13718549#comment-13718549
]
Sylvain Lebresne commented on CASSANDRA-5797:
-
bq. I like LOCAL_SERIAL over ANY
I think there is some confusion. The suggestion of CL.ANY was for the commit
part of Paxos. That part is basically a standard write (that happens after the
paxos algorithm has unfolded but does impact the visibility of the CAS write by
non-serial reads). For that, LOCAL_SERIAL don't really make sense imo (it's
"wrong" even). ANY does is what match the most what happens, because you are
guaranteed the write is replicated somewhere (paxos ensures that) but you may
not be able to see your write right away with normal reads, even at CL.ALL
(which is also something that CL.ANY).
> 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
[jira] [Commented] (CASSANDRA-5797) DC-local CAS
[
https://issues.apache.org/jira/browse/CASSANDRA-5797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13718473#comment-13718473
]
Sylvain Lebresne commented on CASSANDRA-5797:
-
bq. although I think it would be better to come up w/ a different enum for the
Paxos phases than re-use CL
The thing is that for reads, we must have SERIAL and LOCAL_SERIAL in CL if we
want thrift to support it. So once we have them in CL, is it really worth
adding a separate enum for the write case? (honest question, I'm fine doing it,
just wonder if it's worth bothering since things will be mixed up for reads
anyway).
> 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
[jira] [Commented] (CASSANDRA-5797) DC-local CAS
[
https://issues.apache.org/jira/browse/CASSANDRA-5797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13718476#comment-13718476
]
Patrick McFadin commented on CASSANDRA-5797:
I like LOCAL_SERIAL over ANY. It makes a closer match to LOCAL_QUORUM in that
it's not meant to cross datacenter boundaries. There is enough confusion about
ANY as it is and I think this would simplify things.
> 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
[jira] [Commented] (CASSANDRA-5797) DC-local CAS
[
https://issues.apache.org/jira/browse/CASSANDRA-5797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13718464#comment-13718464
]
Jonathan Ellis commented on CASSANDRA-5797:
---
Sounds reasonable, although I think it would be better to come up w/ a
different enum for the Paxos phases than re-use CL, most of whose options are
not appropriate.
I actually think CL.ANY on commit is fine.
> 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
[jira] [Commented] (CASSANDRA-5797) DC-local CAS
[
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
[jira] [Commented] (CASSANDRA-5797) DC-local CAS
[
https://issues.apache.org/jira/browse/CASSANDRA-5797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13717917#comment-13717917
]
Jonathan Ellis commented on CASSANDRA-5797:
---
Not sure what CQL syntax for this is. Is it protocol level the way CL is?
> 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
