You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@cassandra.apache.org by Pranay akula <pr...@gmail.com> on 2016/09/19 20:08:44 UTC
How does Local quorum consistency work ?? response from fastest node?
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
Re: How does Local quorum consistency work ?? response from fastest node?
Posted by Nicolas Douillet <ni...@gmail.com>.
Oki, have fun :)
Le jeu. 22 sept. 2016 à 18:39, Joseph Tech <ja...@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" <ni...@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 <ja...@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.douillet@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 <pr...@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
>>>>>
>>>>
>>>
Re: How does Local quorum consistency work ?? response from fastest node?
Posted by Joseph Tech <ja...@gmail.com>.
Thanks!. I was just trying with default cqlsh ; now realize that its only
ONE CL
On 22 Sep 2016 16:16, "Nicolas Douillet" <ni...@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 <ja...@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.douillet@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 <pr...@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
>>>>
>>>
>>
Re: How does Local quorum consistency work ?? response from fastest node?
Posted by Nicolas Douillet <ni...@gmail.com>.
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 <ja...@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.douillet@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 <pr...@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
>>>
>>
>
Re: How does Local quorum consistency work ?? response from fastest node?
Posted by Joseph Tech <ja...@gmail.com>.
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.douillet@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 <pr...@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
>>
>
Re: How does Local quorum consistency work ?? response from fastest node?
Posted by Nicolas Douillet <ni...@gmail.com>.
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 <pr...@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
>