Hi, Below is a sample trace for a LOCAL_QUORUM query . I've changed the query table/col names and actual node IP addresses to IP.1 and IP.coord (for the co-ordinator node). RF=3 and we have 2 DCs. Don't we expect to see an "IP.2" since LOCAL_QUORUM requires the co-ordinator to receive at least 2 responses? . What am i missing here?
activity | timestamp | source | source_elapsed ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+----------------------------+---------------+---------------- Execute CQL3 query | 2016-09-15 04:17:55.401000 | IP.coord | 0 Parsing SELECT A,B,C from T WHERE key1='K1' and key2='K2' and key3='K3' and key4='K4'; [SharedPool-Worker-2] | 2016-09-15 04:17:55.402000 | IP.coord | 57 Preparing statement [SharedPool-Worker-2] | 2016-09-15 04:17:55.403000 | IP.coord | 140 reading data from /IP.1 [SharedPool-Worker-2] | 2016-09-15 04:17:55.403000 | IP.coord | 1343 Sending READ message to /IP.1 [MessagingService-Outgoing-/IP.1] | 2016-09-15 04:17:55.404000 | IP.coord | 1388 REQUEST_RESPONSE message received from /IP.1 [MessagingService-Incoming-/IP.1] | 2016-09-15 04:17:55.404000 | IP.coord | 2953 Processing response from /IP.1 [SharedPool-Worker-3] | 2016-09-15 04:17:55.404000 | IP.coord | 3001 READ message received from /IP.coord [MessagingService-Incoming-/IP.coord] | 2016-09-15 04:17:55.405000 | IP.1 | 117 Executing single-partition query on user_carts [SharedPool-Worker-1] | 2016-09-15 04:17:55.405000 | IP.1 | 253 Acquiring sstable references [SharedPool-Worker-1] | 2016-09-15 04:17:55.406000 | IP.1 | 262 Merging memtable tombstones [SharedPool-Worker-1] | 2016-09-15 04:17:55.406000 | IP.1 | 295 Bloom filter allows skipping sstable 729 [SharedPool-Worker-1] | 2016-09-15 04:17:55.406000 | IP.1 | 341 Partition index with 0 entries found for sstable 713 [SharedPool-Worker-1] | 2016-09-15 04:17:55.407000 | IP.1 | 411 Seeking to partition indexed section in data file [SharedPool-Worker-1] | 2016-09-15 04:17:55.407000 | IP.1 | 414 Skipped 0/2 non-slice-intersecting sstables, included 0 due to tombstones [SharedPool-Worker-1] | 2016-09-15 04:17:55.407000 | IP.1 | 854 Merging data from memtables and 1 sstables [SharedPool-Worker-1] | 2016-09-15 04:17:55.408000 | IP.1 | 860 Read 1 live and 1 tombstone cells [SharedPool-Worker-1] | 2016-09-15 04:17:55.408000 | IP.1 | 910 Enqueuing response to /IP.coord [SharedPool-Worker-1] | 2016-09-15 04:17:55.408000 | IP.1 | 1051 Sending REQUEST_RESPONSE message to /IP.coord [MessagingService-Outgoing-/IP.coord] | 2016-09-15 04:17:55.409000 | IP.1 | 1110 Request complete | 2016-09-15 04:17:55.404067 | IP.coord | 3067 Thanks, Joseph On Tue, Sep 20, 2016 at 3:07 AM, Nicolas Douillet < nicolas.douil...@gmail.com> wrote: > Hi Pranay, > > I'll try to answer the more precisely as I can. > > Note that what I'm going to explain is valid only for reads, write > requests work differently. > I'm assuming you have only one DC. > > 1. The coordinator gets a list of sorted live replicas. Replicas are > sorted by proximity. > (I'm not sure enough how it works to explain it here, by snitch I > guess). > > 2. By default *the coordinator keeps the exact list of nodes necessary* > to ensure the desired consistency (2 nodes for RF=3), > but, according the read repair chance provided on each column family > (10% of the requests by default), *it might keep all the replicas* (if > one DC). > > 3. The coordinator checks if enough nodes are alive before trying any > request. If not, no need to go further. > You'll have a slightly different error message : > > *Live nodes <list> do not satisfy ConsistencyLevel (2 required) * > 4. And in substance the coordinator waits for the exact number of > responses to achieve the consistency. > To be more specific, the coordinator is not requesting the same to > each involved replicas (to one or two, the closest, a full data read, and > for the others only a digest), and is waiting for the exact number of > responses to achieve the consistency with at least one full data present. > (There is of course more to explain, if the digests do not match for > example ...) > > So you're right when you talk about the fastest responses, but only > under certain conditions and if additional replicas are requested. > > > I'm certainly missing some points. > Is that clear enough? > > -- > Nicolas > > > > Le lun. 19 sept. 2016 à 22:16, Pranay akula <pranay.akula2...@gmail.com> > a écrit : > >> >> >> i always have this doubt when a cassandra node got a read request for >> local quorum consistency does coordinator node asks all nodes with replicas >> in that DC for response or just the fastest responding nodes to it who's >> count satisfy the local quorum. >> >> In this case RF is 3 Cassandra timeout during read query at consistency >> LOCAL_QUORUM (2 responses were required but only 1 replica responded).... >> does this mean coordinator asked only two replicas with fastest response >> for data and 1 out of 2 timed out or coordinator asked all nodes with >> replicas which means all three (3) and 2 out of 3 timed out as i only got >> single response back. >> >> >> >> Thanks >> >> Pranay >> >