This is how getConsistencyLevel method is implemented. This method returns
consistencylevel of the query or null if no consistency level has been set
using setConsistencyLevel.
Regards
Manish
On Fri, Jun 12, 2020 at 3:43 PM Manu Chadha wrote:
> Hi
>
> In my Cassandra Java driver code, I am cr
Yes Jeff, want to achieve the same ( *You’re trying to go local quorum in
one dc to local quorum in the other dc without losing any writes*)
Thanks for your quick response.
Regards
Manish
On Mon, Mar 16, 2020 at 10:58 AM Jeff Jirsa wrote:
>
> You’re trying to go local quorum in one dc to lo
You’re trying to go local quorum in one dc to local quorum in the other dc
without losing any writes?
The easiest way to do this strictly correctly is to take the latency hit and do
quorum while you run repair, then you can switch to local quorum on the other
side.
A few more notes inline
No. Rebuilds don't keep consistency as they aren't smart enough to stream
from a specific replica, this all replicas for a rebuild can stream from a
single replica. You need to repair after rebuilding.
If you're using NTS with #racks >= RF you can stream consistently. if this
patch gets in https:/
t;>
Date: Monday, March 20, 2017 at 6:25 PM
To: "user@cassandra.apache.org<mailto:user@cassandra.apache.org>"
mailto:user@cassandra.apache.org>>
Subject: Re: Consistency Level vs. Retry Policy when no local nodes are
available
I think the general assumption is that DC fa
I think the general assumption is that DC failover happens at the client
app level rather than the Cassandra level due to the potentially very
significant difference in request latency if you move from a app-local DC
to a remote DC. The preferred pattern for most people is that the app fails
in a f
Specifically, this puts us in an awkward position because LOCAL_QUORUM is
desirable so that we don't have unnecessary cross-DC traffic from the client by
default, but we can't use it because it will cause complete failure if the
local DC goes down. And we can't use QUORUM because it would fail i
Yeah, except I guess there's a minor debate left on whether it'd be more
performant to store the labels in their own table, and do a read query each
time when the parent item is fetched.
Or if they should be kept as a set on the parent item and take the
penalty when updating / deleting labels. (Wh
So problem solved!
On Sun, Nov 13, 2016 at 1:37 PM, Ali Akhtar wrote:
> Yeah, I am using set (not set though)
>
> On Sun, Nov 13, 2016 at 5:36 PM, DuyHai Doan wrote:
>
>> Yes you'd have to know the UDT values since it's part of the primary key
>> to query your data.
>>
>> If I were you I would
Yeah, I am using set (not set though)
On Sun, Nov 13, 2016 at 5:36 PM, DuyHai Doan wrote:
> Yes you'd have to know the UDT values since it's part of the primary key
> to query your data.
>
> If I were you I would stick to using a set and use UPDATE my_table
> SET labels = labels + ;
>
> It does
Yes you'd have to know the UDT values since it's part of the primary key to
query your data.
If I were you I would stick to using a set and use UPDATE my_table
SET labels = labels + ;
It does work well with concurrent updates.
On Sun, Nov 13, 2016 at 1:32 PM, Ali Akhtar wrote:
> But then how w
But then how would you query it? You'd need to know all the values of the
udt, right?
On Sun, Nov 13, 2016 at 5:30 PM, DuyHai Doan wrote:
> "Also can you make a UDT a clustered key?" --> yes if it's frozen
>
> On Sun, Nov 13, 2016 at 1:25 PM, Ali Akhtar wrote:
>
>> If I wanted to get all values
"Also can you make a UDT a clustered key?" --> yes if it's frozen
On Sun, Nov 13, 2016 at 1:25 PM, Ali Akhtar wrote:
> If I wanted to get all values for an item, including its labels, how would
> that be done in the above case?
>
> Also can you make a UDT a clustered key?
>
> On Sun, Nov 13, 201
If I wanted to get all values for an item, including its labels, how would
that be done in the above case?
Also can you make a UDT a clustered key?
On Sun, Nov 13, 2016 at 4:33 AM, Manoj Khangaonkar
wrote:
> Hi,
>
> Instead of using a collection, consider making label a clustered column.
>
> Wi
Hi,
Instead of using a collection, consider making label a clustered column.
With this each request will essentially append a column (label) to the
partition.
To get all labels would be a simple query
select label from table where partitionkey = "value".
In general , read + update of a column
"doing mapper.save() will do an insert rather than an update? " --> Yes
The java driver mapper has no update method. To do an update you need to
use the Accessor and roll out your own update statement
On Sat, Nov 12, 2016 at 5:37 PM, Ali Akhtar wrote:
> Just to be clear, doing mapper.save() wil
Just to be clear, doing mapper.save() will do an insert rather than an
update?
On Sat, Nov 12, 2016 at 9:36 PM, Andrew Tolbert wrote:
> I believe you are correct that the implementation taking the Set is the
> right one to use.
>
> On Sat, Nov 12, 2016 at 9:44 AM Ali Akhtar wrote:
>
>> Or it co
I believe you are correct that the implementation taking the Set is the
right one to use.
On Sat, Nov 12, 2016 at 9:44 AM Ali Akhtar wrote:
> Or it could even take Set as the first bound var:
>
> void addLabel(Set label, String id);
>
>
> On Sat, Nov 12, 2016 at 8:41 PM, Ali Akhtar wrote:
>
> A
Or it could even take Set as the first bound var:
void addLabel(Set label, String id);
On Sat, Nov 12, 2016 at 8:41 PM, Ali Akhtar wrote:
> Andrew,
>
> I was thinking about setting up an accessor with that query and a bound
> variable ? which binds to the instance being added, e.g:
>
> @Query(
Andrew,
I was thinking about setting up an accessor with that query and a bound
variable ? which binds to the instance being added, e.g:
@Query("UPDATE my_table SET labels = labels + ? WHERE id = ?")
void addLabel(Label label, String id);
Will that work?
On Sat, Nov 12, 2016 at 8:38 PM, Andrew
You can do it in a SimpleStatement assuming you provide the CQL exactly as
you provided, but in a PreparedStatement it will not work because cql
prohibits provide bind values in collection literals. For it to work you
could provide a List of UDT values in a bound prepared statement, i.e.:
Use
Looks like the trick was to use [] around the udt value literal.
Any way to do this using the java driver?
On Sat, Nov 12, 2016 at 7:58 PM, Ali Akhtar wrote:
> Changing the double quotes to single quotes gives:
>
> UPDATE my_table SET labels = labels + {id: 'foo'} where id = '';
>
> InvalidRequ
Changing the double quotes to single quotes gives:
UPDATE my_table SET labels = labels + {id: 'foo'} where id = '';
InvalidRequest: Error from server: code=2200 [Invalid query]
message="Invalid user type literal for labels of type list>"
On Sat, Nov 12, 2016 at 7:50 PM, Ali Akhtar wrote:
> Th
The question is about appending to a set of frozen and how to do that
while avoiding the race condition.
If I run:
UPDATE my_table SET labels = labels + {id: "foo"} where id = 'xx';
I get:
SyntaxException: line 1:57 no viable alternative at input '}' (...= labels
+ {id: ["fo]o"}...)
Here labe
If I used consistency = ALL both when getting the record, and when saving the
record, will that avoid the race condition?
If I use consistency level = all, will that cause it to end up with [1,2]?
No. Even if you have only one host it's possible that two threads first both
read data and than ov
The labels collection is of the type set> , where label is a
udt containing: id, name, description , all text fields.
On Sat, Nov 12, 2016 at 5:54 PM, Ali Akhtar wrote:
> The problem isn't just the update / insert though, right? Don't frozen
> entities get overwritten completely? So if I had [1]
The problem isn't just the update / insert though, right? Don't frozen
entities get overwritten completely? So if I had [1] [2] being written as
updates, won't each update overwrite the set completely, so i'll end up
with either one of them instead of [1,2]?
On Sat, Nov 12, 2016 at 5:50 PM, DuyHai
Maybe you should use my Achilles mapper, which does generates UPDATE
statements on collections and not only INSERT
Le 12 nov. 2016 13:08, "Ali Akhtar" a écrit :
> I am using the Java Cassandra mapper for all of these cases, so my code
> looks like this:
>
> Item myItem = myaccessor.get( itemId );
I am using the Java Cassandra mapper for all of these cases, so my code
looks like this:
Item myItem = myaccessor.get( itemId );
Mapper mapper = mappingManager.create( Item.class );
myItem.labels.add( newLabel );
mapper.save( myItem );
On Sat, Nov 12, 2016 at 5:06 PM, Ali Akhtar wrote:
> Thank
Thanks DuyHai, I will switch to using a set.
But I'm still not sure how to resolve the original question.
- Original labels = []
- Request 1 arrives with label = 1, and request 2 arrives with label = 2
- Updates are sent to c* with labels = [1] and labels = [2] simultaneously.
What will happen i
Don't use list, use set instead. If you need ordering of insertion, use a
map where timeuuid is generated by the client to guarantee
insertion order
When setting a new value to a list, C* will do a read-delete-write
internally e.g. read the current list, remove all its value (by a range
tombstone)
If I used consistency = ALL both when getting the record, and when saving
the record, will that avoid the race condition?
On Sat, Nov 12, 2016 at 4:26 PM, Ali Akhtar wrote:
> I'm responding to a 3rd party API, so I have no control over sending the
> labels together instead of one by one. In this
I'm responding to a 3rd party API, so I have no control over sending the
labels together instead of one by one. In this case, the API will send them
one by one.
The list is actually of a list> and not a text (I used text
for simplification, apologies).
In that case, will updates still merge the l
Could you not send both labels in one request? Race conditions should still be
handled as Vladimir suggests. But in this specific case the client could send
both as 1 request thus simplifying the solution.
/Oskar
> On 12 nov. 2016, at 12:05, Vladimir Yudovin wrote:
>
> Hi Ali,
>
> >What can
Hi Ali,
>What can I do so I end up with [1, 2] instead of either [1] or [2] after
both requests have been processed?
Use UPDATE, not INSERT. Thus new labels will be added to list, without
overwriting old ones. Also consider usage of SET instead of LIST to avoid
duplicates.
Best regards,
Hi Alain,
Thank you for your answer.
I recently queried multiple times my cluster with consistency ONE and
setting "myLocalDC" (withUsedHostsPerRemoteDc=1)
However sometimes (not always) I got response from the node in the remote
DC. All my nodes in "myLocalDC" were up and running.
I was facing
Hi George,
Would that be correct?
I think it is actually quite the opposite :-).
It is very well explained here:
https://docs.datastax.com/en/drivers/java/2.0/com/datastax/driver/core/policies/DCAwareRoundRobinPolicy.Builder.html#withUsedHostsPerRemoteDc-int-
Connection is opened to the X node
On Thu, Mar 31, 2016 at 4:35 AM, Alain RODRIGUEZ wrote:
> My understanding is using RF 3 and LOCAL_QUORUM for both reads and writes
> will provide a strong consistency and a high availability. One node can go
> down and also without lowering the consistency. Or RF = 5, Quorum = 3,
> allowing 2 no
Hi,
If you want the full immediate consistency of a traditional relational
> database, then go with CL=ALL, otherwise, take your pick from the many
> degrees of immediacy that Cassandra offers:
My understanding is using RF 3 and LOCAL_QUORUM for both reads and writes
will provide a strong consi
The third choice is EACH_QUORUM which assures QUORUM in each data center
(all data centers.)
There is no "immediate consistency" per se in Cassandra. Cassandra offers
"eventual consistency" and "tunable consistency" or the degree of immediate
consistency, which is the CL that you specify - you spe
It did, but a ran it again on one node – that node never recovered. ☹
From: Robert Coli [mailto:rc...@eventbrite.com]
Sent: 02 October 2015 21:20
To: user@cassandra.apache.org
Subject: Re: Consistency Issues
On Fri, Oct 2, 2015 at 1:32 AM, Walsh, Stephen
mailto:stephen.wa...@aspect.com>>
On Fri, Oct 2, 2015 at 1:32 AM, Walsh, Stephen
wrote:
> Sorry for the late reply, I ran the nodetool resetlocalschema on all
> nodes but in the end it just removed all the schemas and crashed the
> applications.
>
> I need to reset and try again. I’ll try get you the gc stats today J
>
FTR, runn
en.wa...@aspect.com]
Sent: 02 October 2015 09:32
To: user@cassandra.apache.org
Subject: RE: Consistency Issues
Sorry for the late reply, I ran the nodetool resetlocalschema on all nodes but
in the end it just removed all the schemas and crashed the applications.
I need to reset and try again. I’ll try ge
:01
To: user@cassandra.apache.org
Subject: Re: Consistency Issues
You say that you don't think GC is your issue... but did you actually check?
The reasons you suggest aren't very convincing. Can you provide your GC
settings, and take a look at jstat --gccause?
http://docs.oracle.co
t;
>
>
> But I really need to understand this best practice that was mentioned (on
> number of CF’s) by Jack Krupansky.
>
> Anyone more information on this?
>
>
>
>
>
> Many thanks for all your help guys keep it coming J
>
> Steve
>
>
>
> *From:*
k...@gmail.com]
> *Sent:* 01 October 2015 14:00
> *To:* user
> *Subject:* Re: Consistency Issues
>
>
>
> Onur, was responding to Stephen's issue.
>
>
>
>
>
> On Thu, Oct 1, 2015 at 8:56 AM, Onur Yalazı
> wrote:
>
> Thank you Jake.
>
>
ode 1 : has all CF’s
>
> Node 2 : has all CF’s
>
> Node 3 : has all CF’s
>
> Node 4 : has all CF’s
>
>
>
>
>
> This is indeed very strange….
>
>
>
>
>
> *From:* Carlos Alonso [mailto:i...@mrcalonso.com]
> *Sent:* 01 October 2015 12:05
> *To:*
Thanks Jake, I’ll try test out 2.1.9 to see if it resolved the issue and ill
try “nodetool resetlocalschema” now to see if it helps.
Cassandra is 2.1.6
OpsCenter is 5.2.1
From: Jake Luciani [mailto:jak...@gmail.com]
Sent: 01 October 2015 14:00
To: user
Subject: Re: Consistency Issues
Onur
Onur, was responding to Stephen's issue.
On Thu, Oct 1, 2015 at 8:56 AM, Onur Yalazı wrote:
> Thank you Jake.
>
> The issue is I do not have missing CF's and upgrading beyond 2.1.3 is not
> a possibility because of the deprecation of cql dialects. Our application
> is using Hector and migrating
Thank you Jake.
The issue is I do not have missing CF's and upgrading beyond 2.1.3 is
not a possibility because of the deprecation of cql dialects. Our
application is using Hector and migrating to cql3 is a huge refactoring.
On 01/10/15 15:48, Jake Luciani wrote:
Couple things to try.
1. n
Couple things to try.
1. nodetool resetlocalschema on the nodes with missing CFs. This will
refresh the schema on the local node.
2. upgrade to 2.1.9. There are some pretty major issues in 2.1.6 (nothing
specific to this problem but worth upgrading)
deed very strange….
>
>
>
>
>
> *From:* Carlos Alonso [mailto:i...@mrcalonso.com]
> *Sent:* 01 October 2015 12:05
> *To:* user@cassandra.apache.org
> *Subject:* Re: Consistency Issues
>
>
>
> And that's a stupid one, I know, but does the column you're tryi
CF’s
This is indeed very strange….
From: Carlos Alonso [mailto:i...@mrcalonso.com]
Sent: 01 October 2015 12:05
To: user@cassandra.apache.org
Subject: Re: Consistency Issues
And that's a stupid one, I know, but does the column you're trying to access
actually exist?
Carlos Alonso | Sof
J
>
>
>
>
>
> *From:* Carlos Alonso [mailto:i...@mrcalonso.com]
> *Sent:* 01 October 2015 10:11
>
> *To:* user@cassandra.apache.org
> *Subject:* Re: Consistency Issues
>
>
>
> Hi Stephen.
>
>
>
> The UnknownColumnFamilyException made me tho
I did think of that and they are all the same version ☺
From: Carlos Alonso [mailto:i...@mrcalonso.com]
Sent: 01 October 2015 10:11
To: user@cassandra.apache.org
Subject: Re: Consistency Issues
Hi Stephen.
The UnknownColumnFamilyException made me thought of a possible schema
disagreement in
help guys keep it coming J
>
> Steve
>
>
>
> *From:* Ricardo Sancho [mailto:sancho.rica...@gmail.com]
> *Sent:* 01 October 2015 09:39
> *To:* user@cassandra.apache.org
> *Subject:* RE: Consistency Issues
>
>
>
> Can you tell us how much time your gcs are taking?
ancho [mailto:sancho.rica...@gmail.com]
Sent: 01 October 2015 09:39
To: user@cassandra.apache.org
Subject: RE: Consistency Issues
Can you tell us how much time your gcs are taking?
Do you see any especially long ones?
On 1 Oct 2015 09:37, "Walsh, Stephen"
mailto:stephen.wa...@aspect.com>> wr
ot the root causing of the
> inconsistency issue.
>
>
>
> Can anyone verify the best practice for number of CF’s?
>
>
>
>
>
> *From:* Robert Coli [mailto:rc...@eventbrite.com]
> *Sent:* 30 September 2015 18:45
> *To:* user@cassandra.apache.org
> *Subject:
September 2015 18:45
To: user@cassandra.apache.org
Subject: Re: Consistency Issues
On Wed, Sep 30, 2015 at 9:06 AM, Walsh, Stephen
mailto:stephen.wa...@aspect.com>> wrote:
We never had these issue with our first run. Its only when we added another 25%
of writes.
As Jack said, you are pr
On Wed, Sep 30, 2015 at 9:06 AM, Walsh, Stephen
wrote:
>
> We never had these issue with our first run. Its only when we added
> another 25% of writes.
>
As Jack said, you are probably pushing your GC over a threshold, leading to
long pause times and inability to meet quorum.
As Sebastian said,
t in best practices for the number of CF’s?
From: Sebastian Estevez [mailto:sebastian.este...@datastax.com]
Sent: 30 September 2015 17:29
To: user@cassandra.apache.org
Subject: Re: Consistency Issues
Can you provide exact details on where your load balancer is? Like Michael
said, you shouldn&#
.
>
>
>
> Many thanks for taking the time to reply Jack
>
>
>
>
>
>
>
> *From:* Jack Krupansky [mailto:jack.krupan...@gmail.com]
> *Sent:* 30 September 2015 16:53
> *To:* user@cassandra.apache.org
> *Subject:* Re: Consistency Issues
>
>
>
> M
these issue with our first run. Its only when we added another 25%
of writes.
Many thanks for taking the time to reply Jack
From: Jack Krupansky [mailto:jack.krupan...@gmail.com]
Sent: 30 September 2015 16:53
To: user@cassandra.apache.org
Subject: Re: Consistency Issues
More than "low hun
More than "low hundreds" (200 or 300 max, and preferably under 100) of
tables/column families is not exactly a recommended best practice. You may
be able to get it to work, but probably only with very heavy tuning (i.e.,
lots of time and playing with options) on your own part. IOW, no quick and
eas
What client are you using?
Official java and python clients should not have a LB between them and the
C* nodes AFAIK.
Why aren't you using 2.1.9?
Have you checked for schema agreement amongst all nodes?
ml
On Wed, Sep 30, 2015 at 11:22 AM, Walsh, Stephen
wrote:
> More information,
>
>
>
> I’
More information,
I've just setup a NTP server to rule out any timing issues.
And I also see this in the Cassandra node log files
MessagingService-Incoming-/172.31.22.4] 2015-09-30 15:19:14,769
IncomingTcpConnection.java:97 - UnknownColumnFamilyException reading from
socket; closing
org.apache.
It looks like NTP was the problem. Thanks for the solution!!!
On Wed, May 13, 2015 at 9:20 AM, Robert Wille wrote:
> Timestamps have millisecond granularity. If you make multiple writes
> within the same millisecond, then the outcome is not deterministic.
>
> Also, make sure you are running n
Timestamps have millisecond granularity. If you make multiple writes within the
same millisecond, then the outcome is not deterministic.
Also, make sure you are running ntp. Clock skew will manifest itself similarly.
On May 13, 2015, at 3:47 AM, Jared Rodriguez
mailto:jrodrig...@kitedesk.com>>
Thanks for the feedback. We have dug in deeper and upgraded to Cassandra
2.0.14 and are seeing the same issue. What appears to be happening is that
if a record is initially written, then the first read is fine. But if we
immediately update that record with a second write, that then the second
re
On Tue, May 12, 2015 at 12:35 PM, Michael Shuler
wrote:
> This is a 4 node cluster running Cassandra 2.0.6
>>
>
> Can you reproduce the same issue on 2.0.14? (or better yet, the
> cassandra-2.0 branch HEAD, which will soon ship 2.0.15) If you get the same
> results, please, open a JIRA with the r
On 05/12/2015 04:50 AM, Jared Rodriguez wrote:
I have a specific update and query that I need to ensure has strong
consistency. To that end, when I do the write, I set the consistency
level to ALL. Shortly afterwards, I do a query for that record with a
consistency of ONE and somehow get back s
Thanks for the detailed answer!
2015-04-30 17:14 GMT+03:00 Jonathan Haddad :
> You can connect to any node in the cluster to issue a query. For that
> request, it's called the coordinator. The coordinator will figure out
> which node to talk to. The DataStax native drivers can use what's calle
You can connect to any node in the cluster to issue a query. For that
request, it's called the coordinator. The coordinator will figure out
which node to talk to. The DataStax native drivers can use what's called
token aware queries, in that they'll connect to one of the nodes that owns
the data
Thank for your response!
I've read the documentation but some points aren't clear for me still. Does
Cassandra support read/write operation only from/to node which is
responsible for this partition (calculated by has)?
2015-04-29 22:43 GMT+03:00 Robert Coli :
> On Wed, Apr 29, 2015 at 8:56 AM, Ni
On Wed, Apr 29, 2015 at 8:56 AM, Nikolay Tikhonov wrote:
> I try to understand how to Cassandra supports data consistency and compare
> it with other distributed caches.
>
For the record, Cassandra is not a distributed cache.
=Rob
There's a lot going on, reading through some docs is probably your best
bet:
http://docs.datastax.com/en/cassandra/2.0/cassandra/dml/dml_config_consistency_c.html
On Wed, Apr 29, 2015 at 8:57 AM Nikolay Tikhonov
wrote:
> Hi,
>
> I try to understand how to Cassandra supports data consistency and
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
Thanks.
I am thinking more in terms of the combination of read/write. If I am
correct, QUORUM reads and QUORUM writes (or ONE-ALL) should deliver
strong consistency in the absence of failures, correct? Or this this
still considered eventual consistency, somehow?
-Bill
On 10/08/2014 06:17 P
I don't know of any such data collected by DataStax - it's not like we're
the NSA, sniffing all requests.
ONE is certainly fast, but only fine if you don't have immediate need to
read the data or don't need the absolutely most recent value.
To be clear, even QUORUM write is eventual consisten
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 (ONE-ONE) in
> production
One should be carefull about using ALL consistency because by doing so, you
sacrify the high availability (loosing one node of the replica prevent you
from writing/reading with ALL). Lots of people choose Cassandra for high
availability so using ALL is kind of showstopper.
Of course there are spe
A follow up on the earlier question.
I meant to ask earlier if control returns to client after batch log is
written on coordinator irrespective of consistency level mentioned.
Also: will the coordinator attempt all statements one after the other, or
in parallel ?
Thanks
On Tue, Sep 16, 2014 at
Thanks, this clears things up.
> On Feb 21, 2014, at 6:47 AM, Edward Capriolo wrote:
>
> When you write at one, as soon as one node acknowledges the write the ack is
> returned to the client. This means if you quickly read from aome other node
> 1)you may get the result because by the time the
When you write at one, as soon as one node acknowledges the write the ack
is returned to the client. This means if you quickly read from aome other
node
1)you may get the result because by the time the read is processed the data
may be on that node
2)the node you read from may proxy the request to
My bad; should have checked the code:
/**
* This function executes local and remote reads, and blocks for the
results:
*
* 1. Get the replica locations, sorted by response time according to the
snitch
* 2. Send a data request to the closest replica, and digest requests to
Hi Graham,
On 21/02/14 07:54, graham sanderson wrote:
Note also; that reading at ONE there will be no read repair, since the
coordinator does not know that another replica has stale data (remember at ONE,
basically only one node is asked for the answer).
I don't think this is right. My unde
Note also; that reading at ONE there will be no read repair, since the
coordinator does not know that another replica has stale data (remember at ONE,
basically only one node is asked for the answer).
In practice for our use cases, we always write at LOCAL_QUORUM (failing the
whole update if th
Writing at a consistency level of ONE means that your write will be
acknowledged as soon as one replica confirms that it has made the write to
memtable and the commit log (might not be quite synced to disk, but that’s a
separate issue).
All the writes are submitted in parallel, so it is very pos
Thanks for the heads up - I'll take a look at the driver.
On Tue, Nov 19, 2013 at 9:57 AM, Sylvain Lebresne wrote:
> 256 is clearly not a valid CL code. It's of course always possible that the
> client sends something perfectly valid and the server interprets it badly
> for some reason, but it's
256 is clearly not a valid CL code. It's of course always possible that the
client sends something perfectly valid and the server interprets it badly
for some reason, but it's a lot more likely a priori that the driver just
sends something wrong. In any case, since as far as I know no-one has seen
I'm not sure that this is entirely causal, but the error I was getting
occurred when the batch size I was accumulating was greater than 130K,
so by cutting the batch size down, I made the issue go away for now.
Having a such a large batch size is probably not such a good idea, but
I'm not really su
To: user@cassandra.apache.org
Subject: Re: consistency level for "create keyspace"?
Further the question below, the same thing seems to happen with
ColumnFamily: If I make a ColumnFamily, and then don't wait long enough, an
attempt to query it can fail if the particular node that
Further the question below, the same thing seems to happen with
ColumnFamily: If I make a ColumnFamily, and then don't wait long enough,
an attempt to query it can fail if the particular node that gets queried
does not know about it yet. Is there something smarter to do than just
try/excep
"user@cassandra.apache.org<mailto:user@cassandra.apache.org>" <
> user@cassandra.apache.org<mailto:user@cassandra.apache.org>>
> Date: Monday, June 3, 2013 2:31 PM
> To: "user@cassandra.apache.org<mailto:user@cassandra.apache.org>" <
> user@cassan
r@cassandra.apache.org>>
Date: Monday, June 3, 2013 2:31 PM
To: "user@cassandra.apache.org<mailto:user@cassandra.apache.org>"
mailto:user@cassandra.apache.org>>
Subject: Re: Consistency level for multi-datacenter setup
We observed that as well, please let us know what
Yup, RF is 2 for both the datacenters.
On Mon, Jun 3, 2013 at 3:36 PM, Sylvain Lebresne wrote:
> What's your replication factor? Do you have RF=2 on both datacenters?
>
>
> On Mon, Jun 3, 2013 at 10:09 PM, srmore wrote:
>
>> I am a bit confused when using the consistency level for multi datacen
What's your replication factor? Do you have RF=2 on both datacenters?
On Mon, Jun 3, 2013 at 10:09 PM, srmore wrote:
> I am a bit confused when using the consistency level for multi datacenter
> setup. Following is my setup:
>
> I have 4 nodes the way these are set up are
> Node 1 DC 1 - N1DC1
We observed that as well, please let us know what you find out it would be
extremely helpful. There is also this property that you can play with to
take care of slow nodes
*dynamic_snitch_badness_threshold*.
http://www.datastax.com/docs/1.1/configuration/node_configuration#dynamic-snitch-badness-
With CL=TWO it appears that one node randomly picks the node from other
datacenter to get the data. i.e. one node in the datacenter consistently
underperforms.
On Mon, Jun 3, 2013 at 3:21 PM, Hiller, Dean wrote:
> What happens when you use CL=TWO.
>
> Dean
>
> From: srmore mailto:comom...@gmai
Also, we had to put a fix into cassandra so it removed "slow nodes" from the
list of nodes to read from. With that fix our QUOROM(not local quorom) started
working again and would easily take the other DC nodes out of the list of
reading from for you as well. I need to circle back to with my t
1 - 100 of 176 matches
Mail list logo
