Oki, have fun :) Le jeu. 22 sept. 2016 à 18:39, Joseph Tech <jaalex.t...@gmail.com> a écrit :
> 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 >>>>> >>>> >>>
