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
>>>>
>>>
>>

Reply via email to