(FallthroughRetryPolicy.INSTANCE);
return statement;
}
So that you can set ConsistencyLevel differently for read and write.
Tks, qihuang.zheng
原始邮件
发件人:Ajay gargajaygargn...@gmail.com
收件人:useru...@cassandra.apache.org
发送时间:2015年10月27日(周二) 02:17
主题:Can consistency-levels be different for "read"
If one rethinks "consistency" to mean "copies returned" and "copies
written" then one can have different values for the former (datastax) and
the latter (within Cassandra). The latter changes eventual consistency
(e.g. two copies must be written), the former can speed up a result at the
(slight) ri
What's your query? Do you have IF NOT EXISTS in there?
On Mon, Oct 26, 2015 at 11:17 AM Ajay Garg wrote:
> Right now, I have setup "LOCAL QUORUM" as the consistency level in the
> driver, but it seems that "SERIAL" is being used during writes, and I
> consistently get this error of type ::
>
>
Right now, I have setup "LOCAL QUORUM" as the consistency level in the
driver, but it seems that "SERIAL" is being used during writes, and I
consistently get this error of type ::
*Cassandra timeout during write query at consistency SERIAL (3 replica were
required but only 0 acknowledged the write
t to use LOCAL_* consistency levels. However, if I write my
> code with LOCAL_* consistency levels, an exception is thrown. I’ve forgotten
> the exact verbiage, but its something about having a NetworkTopologyStrategy
> that doesn’t support local consistency levels. t don’t really want to chang
I’m wondering if there’s a best practice for an annoyance I’ve come across.
Currently all my environments (dev, staging and live) have a single DC. In the
future my live environment will most likely have a second DC. When that
happens, I’ll want to use LOCAL_* consistency levels. However, if I
If I deliberately "decommission" a node, that isn't necessarily a "failure"
is it?
All of that said, "it depends" on where you're trying to get to.
-- Jack Krupansky
-Original Message-
From: William Katsak
Sent: Wednesday, October 8, 2014 7:19 P
clear, even QUORUM write is eventual consistency - to all nodes
beyond the immediate quorum.
-- Jack Krupansky
-Original Message- From: William Katsak
Sent: Wednesday, October 8, 2014 12:27 PM
To: user@cassandra.apache.org
Subject: Consistency Levels
Hello,
I was wondering if anyone
QUORUM write is eventual consistency - to all nodes beyond
the immediate quorum.
-- Jack Krupansky
-Original Message-
From: William Katsak
Sent: Wednesday, October 8, 2014 12:27 PM
To: user@cassandra.apache.org
Subject: Consistency Levels
Hello,
I was wondering if anyone (Datastax?)
On Wed, Oct 8, 2014 at 9:27 AM, William Katsak
wrote:
> I was wondering if anyone (Datastax?) has any usage data about consistency
> levels. For example, what consistency levels are real applications using in
> real production scenarios. Who is using eventual consistency (ON
the anti-entropy processses
(read-repair, consistent read, scheduled repair) to make data converge.
On Wed, Oct 8, 2014 at 6:27 PM, William Katsak
wrote:
> Hello,
>
> I was wondering if anyone (Datastax?) has any usage data about consistency
> levels. For example, what consistenc
Hello,
I was wondering if anyone (Datastax?) has any usage data about
consistency levels. For example, what consistency levels are real
applications using in real production scenarios. Who is using eventual
consistency (ONE-ONE) in production vs strong consistency
(QUORUM-QUORUM, ONE-ALL
Well, it may seem like I'm talking to myself now with this response, but I
cracked open the source and found the answer in fairly short order so I figured
I would share what I found. Datastax folks, please do verify that I'm correct
if you don't mind.
Long story short, BoundStatement initializ
After upgrading to the 2.0 driver branch, I received a lot of warnings about
re-preparing previously prepared statements. I read about this issue, and my
work around was to cache my prepared statements in a Map internally in my app via a common prepare method, where the
string key was the CQL q
erent version of Cassandra, a different
> client and likely have different read/write/delete usage.
>
> Hope that helps.
>
> -Original Message-----
> From: graham sanderson [mailto:gra...@vast.com]
> Sent: 10 November 2013 06:12
> To: user@cassandra.apache.org
>
on [mailto:gra...@vast.com]
Sent: 10 November 2013 06:12
To: user@cassandra.apache.org
Subject: Question about consistency levels
I'm trying to be more succinct this time since no answers on my last attempt.
We are currently using 2.0.2 in test (no C* in production yet), and use
(LOCAL_)QUOR
I’m trying to be more succinct this time since no answers on my last attempt.
We are currently using 2.0.2 in test (no C* in production yet), and use
(LOCAL_)QUORUM CL on read and writes which guarantees (if successful) that we
read latest data.
That said, it is highly likely that (LOCAL_)ONE w
On Fri, Jun 10, 2011 at 1:09 PM, AJ wrote:
> It says "all nodes". Shouldn't it say "replication_factor nodes"?
My preferred phrasing would be "all replicas."
> I can understand this if the given row already exists from a previous write
> and one of the nodes that contains a replica is down. Bu
The O'Reilly book on Cass says this about READ consistency level ALL:
"Query all nodes. Wait for all nodes to respond, and return to the
client the record with the most recent timestamp. Then, if necessary,
perfrom a read repair in the background. If any nodes fail or respond,
fail the read o
day, May 2, 2011 1:26:31 PM
Subject: Specifying exact nodes for Consistency Levels
Is it possible in some way to specify what specific nodes I want to
include (or exclude) from the Consistency Level fulfillment ?
Example, I have a cluster of 4 nodes (n1,n2,n3 and n4) and set N=4. I
want to set W=
No.
On Mon, May 2, 2011 at 12:26 PM, A J wrote:
> Is it possible in some way to specify what specific nodes I want to
> include (or exclude) from the Consistency Level fulfillment ?
> Example, I have a cluster of 4 nodes (n1,n2,n3 and n4) and set N=4. I
> want to set W=3 and want to ensure that i
Is it possible in some way to specify what specific nodes I want to
include (or exclude) from the Consistency Level fulfillment ?
Example, I have a cluster of 4 nodes (n1,n2,n3 and n4) and set N=4. I
want to set W=3 and want to ensure that it is n1,n2 and n3 only that
are used to satisfy w=3 (i.e.
22 matches
Mail list logo
