Re: Replication factor, LOCAL_QUORUM write consistency and materialized views

Hi, On Fri, May 17, 2024 at 6:18 PM Jon Haddad wrote: > I strongly suggest you don't use materialized views at all. There are > edge cases that in my opinion make them unsuitable for production, both in > terms of cluster stability as well as data integrity. > Oh, there is already an open and

Re: Replication factor, LOCAL_QUORUM write consistency and materialized views

Hi, On Fri, May 17, 2024 at 6:18 PM Jon Haddad wrote: > I strongly suggest you don't use materialized views at all. There are > edge cases that in my opinion make them unsuitable for production, both in > terms of cluster stability as well as data integrity. > I totally agree with you about it

Re: Replication factor, LOCAL_QUORUM write consistency and materialized views

I strongly suggest you don't use materialized views at all. There are edge cases that in my opinion make them unsuitable for production, both in terms of cluster stability as well as data integrity. Jon On Fri, May 17, 2024 at 8:58 AM Gábor Auth wrote: > Hi, > > I know, I know, the materialize

Re: Replication Factor Change

Hello OK i got it , so i should set CL to ALL for reads, otherwise data may be retrieved from nodes that does not have yet current record. Thanks for help. Yulian Oifa On Thu, Nov 5, 2015 at 5:33 PM, Eric Stevens wrote: > If you switch reads to CL=LOCAL_ALL, you should be able to increase RF, >

RE: Replication Factor Change

Hello, If current CL = ONE, Be careful on production at the time of change replication factor, 3 nodes will be queried while data is being transformed ==> So data read errors! De : Yulian Oifa [mailto:oifa.yul...@gmail.com] Envoyé : jeudi 5 novembre 2015 16:02 À : user@cassandra.apache.org Objet

Re: Replication Factor Change

If you switch reads to CL=LOCAL_ALL, you should be able to increase RF, then run repair, and after repair is complete, go back to your old consistency level. However, while you're operating at ALL consistency, you have no tolerance for a node failure (but at RF=1 you already have no tolerance for

Re: Re : Replication factor for system_auth keyspace

thanks guys for the advice. We were running parallel repairs earlier, with cassandra version 2.0.14. As pointed out having set the replication factor really huge for system_auth was causing the repair to take really long. thanks Sai On Fri, Oct 16, 2015 at 9:56 AM, Victor Chen wrote: > To elabo

Re: Re : Replication factor for system_auth keyspace

To elaborate on what Robert said, I think with most things technology related, the answer with these sorts of questions (i.e. "ideal settings") is usually "it depends." Remember that technology is a tool that we use to accomplish something we want. It's just a mechanism that we as humans use to exe

Re: Re : Replication factor for system_auth keyspace

On Thu, Oct 15, 2015 at 10:24 AM, sai krishnam raju potturi < pskraj...@gmail.com> wrote: > we are deploying a new cluster with 2 datacenters, 48 nodes in each DC. > For the system_auth keyspace, what should be the ideal replication_factor > set? > > We tried setting the replication factor equal

Re : Replication factor for system_auth keyspace

hi; we are deploying a new cluster with 2 datacenters, 48 nodes in each DC. For the system_auth keyspace, what should be the ideal replication_factor set? We tried setting the replication factor equal to the number of nodes in a datacenter, and the repair for the system_auth keyspace took really

Re: Replication factor 2 with immutable data

On Fri, Jul 25, 2014 at 10:46 AM, Jon Travis wrote: > I have a couple questions regarding the availability of my data in a RF=2 > scenario. > You have just explained why consistency does not work with Replication Factor of fewer than 3 and Consistency Level of less than QUORUM. Basically, with

Re: Replication Factor question

On Wed, Apr 16, 2014 at 1:47 AM, Markus Jais wrote: > thanks. How many nodes to you have running in those 5 racks and RF 5? Only > 5 nodes or more? > While I haven't contemplated it too much, I'd think the absolute minimum would be RF=N=5, sure. The "real minimum" with headroom would depend on w

Re: Replication Factor question

Hi Rob, thanks. How many nodes to you have running in those 5 racks and RF 5? Only 5 nodes or more? Markus Robert Coli schrieb am 20:36 Dienstag, 15.April 2014: On Tue, Apr 15, 2014 at 6:14 AM, Ken Hancock wrote: > >Keep in mind if you lose the wrong two, you can't satisfy quorum.  In a 5-no

Re: Replication Factor question

It is not common, but I know of multiple organizations running with RF=5, in at least one DC, for HA reasons. -Tupshin On Apr 15, 2014 2:36 PM, "Robert Coli" wrote: > On Tue, Apr 15, 2014 at 6:14 AM, Ken Hancock wrote: > >> Keep in mind if you lose the wrong two, you can't satisfy quorum. In a

Re: Replication Factor question

On Tue, Apr 15, 2014 at 6:14 AM, Ken Hancock wrote: > Keep in mind if you lose the wrong two, you can't satisfy quorum. In a > 5-node cluster with RF=3, it would be impossible to lose 2 nodes without > affecting quorum for at least some of your data. In a 6 node cluster, once > you've lost one no

Re: Replication Factor question

Hi Ken, thanks. Good point.  Markus Ken Hancock schrieb am 15:15 Dienstag, 15.April 2014: Keep in mind if you lose the wrong two, you can't satisfy quorum.  In a 5-node cluster with RF=3, it would be impossible to lose 2 nodes without affecting quorum for at least some of your data. In a 6 n

Re: Replication Factor question

Keep in mind if you lose the wrong two, you can't satisfy quorum. In a 5-node cluster with RF=3, it would be impossible to lose 2 nodes without affecting quorum for at least some of your data. In a 6 node cluster, once you've lost one node, if you were to lose another, you only have a 1-in-5 chanc

Re: Replication Factor question

Hi all, thanks for your answers. Very helpful. We plan to use enough nodes so that the failure of 1 or 2 machines is no problem. E.g. for a workload to can be handled by 3 nodes all the time, we would use at least 5, better 6 nodes to survive the failure of at least 2 nodes, even when the 2 nod

Re: Replication Factor question

tl;dr make sure you have enough capacity in the event of node failure. For light workloads, that can be fulfilled with nodes=rf. -Tupshin On Apr 14, 2014 2:35 PM, "Robert Coli" wrote: > On Mon, Apr 14, 2014 at 2:25 AM, Markus Jais wrote: > >> "It is generally not recommended to set a replicatio

Re: Replication Factor question

On Mon, Apr 14, 2014 at 2:25 AM, Markus Jais wrote: > "It is generally not recommended to set a replication factor of 3 if you > have fewer than six nodes in a data center". > I have a detailed post about this somewhere in the archives of this list (which I can't seem to find right now..) but br

Re: Replication Factor question

With 3 nodes, and RF=3, you can always use CL=ALL if all nodes are up, QUORUM if 1 node is down, and ONE if any two nodes are down. The exact same thing is true if you have more nodes. -Tupshin On Apr 14, 2014 7:51 AM, "Markus Jais" wrote: > Hi all, > > thanks. Very helpful. > > @Tupshin: With

Re: Replication Factor question

Hi all, thanks. Very helpful. @Tupshin: With a 3 node cluster and RF 3 isn't it a problem if one node fails (due to hardware problems, for example). According to the C* docs, writes fail if the number of nodes is smaller than the RF. I agree that it will run fine as long as all nodes are up and

Re: Replication Factor question

I do not agree with this advice. It can be perfectly reasonable to have #nodes < 2*RF. It is common to deploy a 3 node cluster with RF=3 and it works fine as long as each node can handle 100% of your data, and keep up with the workload. -Tupshin On Apr 14, 2014 5:25 AM, "Markus Jais" wrote: >

Re: Replication Factor question

Hi Markus, > "It is generally not recommended to set a replication factor of 3 if > you have fewer than six nodes in a data center". Actually you can create a cluster with 3 nodes and replication level 3. But in this case if one of them would fail cluster become inconsistent. In this way minimum re

Re: replication factor is zero

But afaik you can set the RF only per Keyspace. So you will have to pull those tables apart, in a different Keyspace. 2013/6/6 Tyler Hobbs > > On Thu, Jun 6, 2013 at 1:28 PM, Daning Wang wrote: > >> could we set replication factor to 0 on other data center? what is the >> best to way for not s

Re: replication factor is zero

On Thu, Jun 6, 2013 at 1:28 PM, Daning Wang wrote: > could we set replication factor to 0 on other data center? what is the > best to way for not syncing some data in a cluster? Yes, you can set it to 0, and that's the recommended way to handle this. -- Tyler Hobbs DataStax

Re: Replication Factor and Consistency Level Confusion

>> this actually what is happening, how is it possible to ever have a >> node-failure resiliant cassandra cluster? Background http://thelastpickle.com/2011/06/13/Down-For-Me/ > I would suggest double-checking your test setup; also, make sure you > use the same row keys every time (if this is not

Re: Replication Factor and Consistency Level Confusion

On Thu, Dec 20, 2012 at 11:26 AM, Vasileios Vlachos wrote: > Initially we were thinking the same thing, that an explanation would > be that the "wrong" node could be down, but then isn't this something > that hinted handoff sorts out? If a node is partitioned from the rest of the cluster (ie. the

Re: Replication Factor and Consistency Level Confusion

Don't run with a replication factor of 2, use 3 instead, and do all reads and writes using quorum consistency. That way, if a single node is down, all your operations will complete. In fact, if every third node is down, you'll still be fine and able to handle all requests. However, if two adjacen

Re: Replication Factor and Consistency Level Confusion

Hello, Thank you very much for your quick responses. Initially we were thinking the same thing, that an explanation would be that the "wrong" node could be down, but then isn't this something that hinted handoff sorts out? So actually, Consistency Level refers to the number of replicas, not the t

Re: Replication Factor and Consistency Level Confusion

Ps, you may be getting a bit confused by the way. Just think if you have a 10 node cluster and one node is down and you do CL=2Š..if the node that is down is where your data goes, yes, you will fail. If you do CL=quorum and RF=3 you can tolerate one node being downŠIf you use astyanax, I think t

Re: Replication Factor and Consistency Level Confusion

ANY: worked (expected...) ONE: worked (expected...) TWO: did not work (WHT???) This is expected sometimes and sometimes not. It depends on the 2 of the 3 nodes that have the data. Since you have one node down, that might be the one where that data goes ;). THREE: did not work (expected...)

Re: Replication factor and performance questions

@oleg, to answer your last question a cassandra node should never ask another node for information it doesn't have. it uses the key and the partitioner to determine where the data is located before ever contacting another node. On Mon, Nov 5, 2012 at 9:45 AM, Andrey Ilinykh wrote: > You will hav

Re: Replication factor and performance questions

You will have one extra hop. Not big deal, actually. And many client libraries (astyanax for example) are token aware, so they are smart enough to call the right node. On Mon, Nov 5, 2012 at 9:12 AM, Oleg Dulin wrote: > Should be all under 400Gig on each. > > My question is -- is there additional

Re: Replication factor and performance questions

Should be all under 400Gig on each. My question is -- is there additional overhead with replicas making requests to one another for keys they don't have ? how much of an overhead is that ? On 2012-11-05 17:00:37 +, Michael Kjellman said: Rule of thumb is to try to keep nodes under 400GB

Re: Replication factor and performance questions

Our compactions/repairs have already become nightmares and we have not approached the levels of data you describe here (~200 GB). Have any pointers/case studies for optimizing this? On Nov 5, 2012, at 12:00 PM, Michael Kjellman wrote: > Rule of thumb is to try to keep nodes under 400GB. > Comp

Re: Replication factor and performance questions

Rule of thumb is to try to keep nodes under 400GB. Compactions/Repairs/Move operations etc become a nightmare otherwise. How much data do you expect to have on each node? Also depends on caches, bloom filters etc On 11/5/12 8:57 AM, "Oleg Dulin" wrote: >I have 4 nodes at my disposal. > >I can co

Re: Replication factor 2, consistency and failover

Aaron, thank you! Your message was exactly what we wanted to see: that we didn't miss something critical. We'll share our Astyanax patch in the future. On 10 September 2012 03:44, aaron morton wrote: > In general we want to achieve strong consistency. > > You need to have R + W > N > > LOCAL_QUO

Re: Replication factor 2, consistency and failover

> In general we want to achieve strong consistency. You need to have R + W > N > LOCAL_QUORUM and reads with ONE. Gives you 2 + 1 > 2 when you use it. When you drop back to ONE / ONE you no longer have strong consistency. > may be advise on how to improve it. Sounds like you know how to impr

Re: Replication factor - Consistency Questions

when got >> "UnavailableException" exception. >> >> 2012/7/18 Jay Parashar >> Thanks..but write ALL will fail for any downed nodes. I am thinking of >> QUORAM. >> >> >> From: Jason Tang [mailto:ares.t...@gmail.com] >> Sent: Tuesday, July

Re: Replication factor - Consistency Questions

To:* user@cassandra.apache.org <mailto:user@cassandra.apache.org> *Subject:* Re: Replication factor - Consistency Questions Hi I am starting using Cassandra for not a long time, and also have problems in consistency. Here is some thinking. If you have Write:Any / Read:One,

Re: Replication factor - Consistency Questions

g of > QUORAM. > > ** ** > > *From:* Jason Tang [mailto:ares.t...@gmail.com] > *Sent:* Tuesday, July 17, 2012 8:24 PM > *To:* user@cassandra.apache.org > *Subject:* Re: Replication factor - Consistency Questions > > ** ** > > Hi > > ** ** > > I a

RE: Replication factor - Consistency Questions

Thanks..but write ALL will fail for any downed nodes. I am thinking of QUORAM. From: Jason Tang [mailto:ares.t...@gmail.com] Sent: Tuesday, July 17, 2012 8:24 PM To: user@cassandra.apache.org Subject: Re: Replication factor - Consistency Questions Hi I am starting using Cassandra for

Re: Replication factor - Consistency Questions

Hi I am starting using Cassandra for not a long time, and also have problems in consistency. Here is some thinking. If you have Write:Any / Read:One, it will have consistency problem, and if you want to repair, check your schema, and check the parameter "Read repair chance: " http://wiki.apache.o

Re: Replication factor

e in error, please contact the sender immediately and > irrevocably delete this message and any copies. > > From: aaron morton [mailto:aa...@thelastpickle.com] > Sent: Thursday, May 24, 2012 13:00 > To: user@cassandra.apache.org > Subject: Re: Replication factor > > Your ex

RE: Replication factor

message in error, please contact the sender immediately and irrevocably delete this message and any copies. From: aaron morton [mailto:aa...@thelastpickle.com] Sent: Thursday, May 24, 2012 13:00 To: user@cassandra.apache.org Subject: Re: Replication factor Your experience is when using CL ONE the Dynamic

Re: Replication factor

contact the sender immediately and > irrevocably delete this message and any copies. > > From: Brandon Williams [mailto:dri...@gmail.com] > Sent: Thursday, May 24, 2012 02:35 > To: user@cassandra.apache.org > Subject: Re: Replication factor > > On Wed, May 23, 2012 at 5:5

Re: Replication factor

rty of the sender. You must not use, > disclose, distribute, copy, print or rely on this e-mail. If you have > received this message in error, please contact the sender immediately and > irrevocably delete this message and any copies. > > From: aaron morton [mailto:aa...@thelastpic

RE: Replication factor

a.apache.org Subject: Re: Replication factor On Wed, May 23, 2012 at 5:51 AM, Viktor Jevdokimov mailto:viktor.jevdoki...@adform.com>> wrote: > When RF == number of nodes, and you read at CL ONE you will always be reading > locally. "always be reading locally" - only if Dynamic Snit

Re: Replication factor

On Wed, May 23, 2012 at 5:51 AM, Viktor Jevdokimov < viktor.jevdoki...@adform.com> wrote: > > When RF == number of nodes, and you read at CL ONE you will always be > reading locally. > > “always be reading locally” – only if Dynamic Snitch is “off”. With > dynamic snitch “on” request may be r

Re: Replication factor

nt or rely on this e-mail. If you have > received this message in error, please contact the sender immediately and > irrevocably delete this message and any copies. > > *From:* aaron morton [mailto:aa...@thelastpickle.com] > *Sent:* Wednesday, May 23, 2012 13:00 > *To:* user@c

RE: Replication factor

this message and any copies. From: aaron morton [mailto:aa...@thelastpickle.com] Sent: Wednesday, May 23, 2012 13:00 To: user@cassandra.apache.org Subject: Re: Replication factor RF is normally adjusted to modify availability (see http://thelastpickle.com/2011/06/13/Down-For-Me/) for example, i

Re: Replication factor

RF is normally adjusted to modify availability (see http://thelastpickle.com/2011/06/13/Down-For-Me/) > for example, if I have 4 nodes cluster in one data center, how can RF=2 vs > RF=4 affect read performance? If consistency level is ONE, looks reading does > not need to go to another hop to g

Re: Replication factor per column family

Ok, that's clear, thank you for your time! 2012/2/16 aaron morton > yes. > > - > Aaron Morton > Freelance Developer > @aaronmorton > http://www.thelastpickle.com > > On 16/02/2012, at 10:15 PM, R. Verlangen wrote: > > Hmm ok. This means if I want to have a CF with RF = 3 and anot

Re: Replication factor per column family

yes. - Aaron Morton Freelance Developer @aaronmorton http://www.thelastpickle.com On 16/02/2012, at 10:15 PM, R. Verlangen wrote: > Hmm ok. This means if I want to have a CF with RF = 3 and another CF with RF > = 1 (e.g. some debug logging) I will have to create 2 keyspaces? >

Re: Replication factor per column family

Hmm ok. This means if I want to have a CF with RF = 3 and another CF with RF = 1 (e.g. some debug logging) I will have to create 2 keyspaces? 2012/2/16 aaron morton > Multiple CF mutations for a row are treated atomically in the commit log, > and they are sent together to the replicas. Replicati

Re: Replication factor per column family

Multiple CF mutations for a row are treated atomically in the commit log, and they are sent together to the replicas. Replication occurs at the row level, not the row+cf level. If each CF had it's own RF, odd things may happen. Like sending a batch mutation for one row and two CF's that fails

Re: Replication factor and other schema changes in >= 0.7

Cool, thanks. I suspected the same, including the repair. On 08/20/2010 06:05 AM, Gary Dusbabek wrote: It is coming. In fact, I started working on this ticket yesterday. Most of the settings that you could change before will be modifiable. Unfortunately, you must still manually perform the re

Re: Replication factor and other schema changes in >= 0.7

It is coming. In fact, I started working on this ticket yesterday. Most of the settings that you could change before will be modifiable. Unfortunately, you must still manually perform the repair operations, etc., afterward. https://issues.apache.org/jira/browse/CASSANDRA-1285 Gary. On Thu, Aug

Re: Replication Factor and Data Centers

(moving to user@) On Mon, Jun 14, 2010 at 10:43 PM, Masood Mortazavi wrote: > Is the clearer interpretation of this statement (in > conf/datacenters.properties) given anywhere else? > > # The sum of all the datacenter replication factor values should equal > # the replication factor of the keyspa