Re: Curiosity in adding nodes
If I understand correctly this is controlled by setting `auto_bootstrap`. If it is set to true (the default), once the node joins the cluster it will have some portion of the data assigned to it, and its data will be streamed to it from the other nodes. Once the data has finished streaming only then will this node start to answer queries. So to answer your question, > Or is new nodes not used until all data is streamed? Yes, by default. You probably do not want to set `auto_bootstrap` to false. In fact, it is "hidden" in `cassandra.yaml` ( https://issues.apache.org/jira/browse/CASSANDRA-2447). To see why you do not want to set it to false there are a couple of nice articles: https://monzo.com/blog/2019/09/08/why-monzo-wasnt-working-on-july-29th https://thelastpickle.com/blog/2017/05/23/auto-bootstrapping-part1.html On Tue, Oct 22, 2019 at 10:54 AM Eunsu Kim wrote: > Hi experts, > > When a new node was added, how can the coordinator find data that has been > not yet streamed? > > Or is new nodes not used until all data is streamed? > > Thanks in advance > - > To unsubscribe, e-mail: user-unsubscr...@cassandra.apache.org > For additional commands, e-mail: user-h...@cassandra.apache.org > >
Re: Necessary consistency level for LWT writes
Dear Hiro, Thank you! Yes, this is exactly my understanding. Is this explicitly written down anywhere or can any expert confirm? I suppose I should read the code but its a little intimidating. Best wishes, Craig On Fri, May 24, 2019 at 11:11 AM Hiroyuki Yamada wrote: > Hi Craig, > > Now I probably understand what the python doc is saying. > > As long as `serial_consistency_level` is set to SERIAL for paxos phase > and `consistency_level` is set to SERIAL for the later read, > conflicts in paxos table can be properly detected, so > `consistency_level` for commit phase can be anything (can be ANY as > the doc says). > Unfinished record write (commit) will be repaired in the read if any. > But, if `consistency_level` is set to others (like ALL) for the later > read, it won't be able to detect conflicts in the paxos table, so it > does not work as expected. > > I'm not sure if it answers your question, but makes sense ? > Craig. > > Is this understanding correct ? > C* professionals. > > Thanks, > Hiro > > On Fri, May 24, 2019 at 10:49 AM Craig Pastro wrote: > > > > Dear Hiro, > > > > Thank you for your response! > > > > Hmm, my understanding is slightly different I think. Please let me try > to explain one situation and let me know what you think. > > > > 1. Do a LWT write with serial_consistency = SERIAL (default) and > consistency = ONE. > > 2. LWT starts its Paxos phase and has communicated with a quorum of nodes > > 3. At this point a read of that data is initiated with consistency = > SERIAL. > > > > Now, here is where I am confused. What I think happens is that a SERIAL > read will read from a quorum of nodes and detect that the Paxos phase is > underway and... maybe wait until it is over before responding with the > latest data? The Paxos phase happens between a quorum so basically even > though the consistency level is ONE (or indeed ANY as the Python docs > state), doing a read with SERIAL implies that the write actually took place > at a consistency level equivalent to QUORUM. > > > > Here also what I think is that a read initiated when the Paxos phase is > underway with a consistency level of QUORUM or ALL will not detect that a > Paxos phase is underway and return the old current data. > > > > Is this correct? > > > > Thank you for any help! > > > > Best wishes, > > Craig > > > > > > > > > > > > > > On Fri, May 24, 2019 at 9:58 AM Hiroyuki Yamada > wrote: > >> > >> Hi Craig, > >> > >> I'm not 100 % sure about some corner cases, > >> but I'm sure that LWT should be used with the following consistency > >> levels usually. > >> > >> LWT write: > >> serial_consistency_level: SERIAL > >> consistency_level: QUORUM > >> > >> LWT read: > >> consistency_level: SERIAL > >> (It's a bit weird and mis-leading as a design that you can set SERIAL > >> to consistency_level in read where as you can't for write.) > >> > >> BTW, I doubt the python doc is correct in especially the following part. > >> "But if the regular consistency_level of that write is ANY, then only > >> a read with a consistency_level of SERIAL is guaranteed to see it > >> (even a read with consistency ALL is not guaranteed to be enough)." > >> It is really true? > >> It doesn't really make sense to me because SERIAL read mostly returns > >> by seeing quorum of replications, > >> and write with ANY returns by writing mostly one replication, so they > >> don't overlap in that case. > >> It would be great if anyone can clarify this. > >> > >> Thanks, > >> Hiro > >> > >> > >> On Thu, May 23, 2019 at 3:53 PM Craig Pastro wrote: > >> > > >> > Hello! > >> > > >> > I am trying to understand the consistency level (not serial > consistency) required for LWTs. Basically what I am trying to understand is > that if a consistency level of ONE is enough for a LWT write operation if I > do my read with a consistency level of SERIAL? > >> > > >> > It would seem so based on what is written for the datastax python > driver: > >> > > >> > > http://datastax.github.io/python-driver/api/cassandra/query.html#cassandra.query.Statement.serial_consistency_level > >> > > >> > However, that is the only place that I can find this information so I > am a little hesitant to believe it 100%. > >> > > >> > By the way, I did find basically the same question ( > https://www.mail-archive.com/user@cassandra.apache.org/msg45453.html) but > I am unsure if the answer there really answers my question. > >> > > >> > Thank you in advance for any help! > >> > > >> > Best regards, > >> > Craig > >> > > >> > > >> > >> - > >> To unsubscribe, e-mail: user-unsubscr...@cassandra.apache.org > >> For additional commands, e-mail: user-h...@cassandra.apache.org > >> > > - > To unsubscribe, e-mail: user-unsubscr...@cassandra.apache.org > For additional commands, e-mail: user-h...@cassandra.apache.org > >
Re: Necessary consistency level for LWT writes
Dear Hiro, Thank you for your response! Hmm, my understanding is slightly different I think. Please let me try to explain one situation and let me know what you think. 1. Do a LWT write with serial_consistency = SERIAL (default) and consistency = ONE. 2. LWT starts its Paxos phase and has communicated with a quorum of nodes 3. At this point a read of that data is initiated with consistency = SERIAL. Now, here is where I am confused. What I think happens is that a SERIAL read will read from a quorum of nodes and detect that the Paxos phase is underway and... maybe wait until it is over before responding with the latest data? The Paxos phase happens between a quorum so basically even though the consistency level is ONE (or indeed ANY as the Python docs state), doing a read with SERIAL implies that the write actually took place at a consistency level equivalent to QUORUM. Here also what I think is that a read initiated when the Paxos phase is underway with a consistency level of QUORUM or ALL will not detect that a Paxos phase is underway and return the old current data. Is this correct? Thank you for any help! Best wishes, Craig On Fri, May 24, 2019 at 9:58 AM Hiroyuki Yamada wrote: > Hi Craig, > > I'm not 100 % sure about some corner cases, > but I'm sure that LWT should be used with the following consistency > levels usually. > > LWT write: > serial_consistency_level: SERIAL > consistency_level: QUORUM > > LWT read: > consistency_level: SERIAL > (It's a bit weird and mis-leading as a design that you can set SERIAL > to consistency_level in read where as you can't for write.) > > BTW, I doubt the python doc is correct in especially the following part. > "But if the regular consistency_level of that write is ANY, then only > a read with a consistency_level of SERIAL is guaranteed to see it > (even a read with consistency ALL is not guaranteed to be enough)." > It is really true? > It doesn't really make sense to me because SERIAL read mostly returns > by seeing quorum of replications, > and write with ANY returns by writing mostly one replication, so they > don't overlap in that case. > It would be great if anyone can clarify this. > > Thanks, > Hiro > > > On Thu, May 23, 2019 at 3:53 PM Craig Pastro wrote: > > > > Hello! > > > > I am trying to understand the consistency level (not serial consistency) > required for LWTs. Basically what I am trying to understand is that if a > consistency level of ONE is enough for a LWT write operation if I do my > read with a consistency level of SERIAL? > > > > It would seem so based on what is written for the datastax python driver: > > > > > http://datastax.github.io/python-driver/api/cassandra/query.html#cassandra.query.Statement.serial_consistency_level > > > > However, that is the only place that I can find this information so I am > a little hesitant to believe it 100%. > > > > By the way, I did find basically the same question ( > https://www.mail-archive.com/user@cassandra.apache.org/msg45453.html) but > I am unsure if the answer there really answers my question. > > > > Thank you in advance for any help! > > > > Best regards, > > Craig > > > > > > - > To unsubscribe, e-mail: user-unsubscr...@cassandra.apache.org > For additional commands, e-mail: user-h...@cassandra.apache.org > >
Necessary consistency level for LWT writes
Hello! I am trying to understand the consistency level (not serial consistency) required for LWTs. Basically what I am trying to understand is that if a consistency level of ONE is enough for a LWT write operation if I do my read with a consistency level of SERIAL? It would seem so based on what is written for the datastax python driver: http://datastax.github.io/python-driver/api/cassandra/query.html#cassandra.query.Statement.serial_consistency_level However, that is the only place that I can find this information so I am a little hesitant to believe it 100%. By the way, I did find basically the same question ( https://www.mail-archive.com/user@cassandra.apache.org/msg45453.html) but I am unsure if the answer there really answers my question. Thank you in advance for any help! Best regards, Craig
