Thanks!. I was just trying with default cqlsh ; now realize that its only ONE CL
On 22 Sep 2016 16:16, "Nicolas Douillet" <nicolas.douil...@gmail.com> wrote: > Hi Joseph, > > The coordinator itself could be one of the replica that holds the data, > but looks like it's not your case. > So you're right the coordinator should have sent a digest request to > another node. > Did you executed this request with cql ? Are you sure you have correctly > set the consistency before executing the request ? > > -- > Nicolas > > > > Le jeu. 22 sept. 2016 à 11:52, Joseph Tech <jaalex.t...@gmail.com> a > écrit : > >> 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 >>>> >>> >>
