What you describe is true for writes but not reads. The read only gets sent to enough nodes to meet the consistency level, unless/until one of two things happen: - You trigger probabilistic read repair, in which case it's sent to all nodes (or all nodes in a DC), or - One of the chosen replicas is too slow to respond, in which case speculative retry triggers and extra read commands are sent.
EVEN IF it was sent to all hosts in a DC and it responded to the client when a sufficient CL was met (on reads), that doesn't ever guarantee that the coordinator is the first to respond (or is guaranteed to respond, could hit tombstone overwhelming or have very slow reads due to compaction / IO / gc / slow disks / bad memory / etc). On Wed, Nov 11, 2020 at 6:36 AM Durity, Sean R <sean_r_dur...@homedepot.com> wrote: > Doesn’t the read get sent to all nodes that own the data in parallel (from > the coordinator)? And the first one that is able to respond wins (for > LOCAL_ONE). That was my understanding. > > > > Sean Durity > > > > *From:* Jeff Jirsa <jji...@gmail.com> > *Sent:* Wednesday, November 11, 2020 9:24 AM > *To:* user@cassandra.apache.org > *Subject:* [EXTERNAL] Re: local read from coordinator > > > > > This isn’t necessarily true and cassandra has no coordinator-only > consistency level to force this behavior > > > > (The snitch is going to pick the best option for local_one reads and any > compactions or latency deviations from load will make it likely that > another replica is chosen in practice) > > > > On Nov 11, 2020, at 3:46 AM, Alex Ott <alex...@gmail.com> wrote: > > > > if you force routing key, then the replica that owns the data will be > selected as coordinator > > > > On Wed, Nov 11, 2020 at 12:35 PM onmstester onmstester < > onmstes...@zoho.com.invalid> wrote: > > Thanx, > > > > But i'm OK with coordinator part, actually i was looking for kind of read > CL to force to read from the coordinator only with no other connections to > other nodes! > > > > Sent using Zoho Mail [zoho.com] > <https://urldefense.com/v3/__https:/www.zoho.com/mail/__;!!M-nmYVHPHQ!dXosmgU9wrmIw7b4y8Xioii9P_OuSN-mvaCcAKCbdGEzSRBZO20Ibpqoyl9WNDHOGg-w1A4$> > > > > > > > > ============ Forwarded message ============ > From: Alex Ott <alex...@gmail.com> > To: "user"<user@cassandra.apache.org> > Date: Wed, 11 Nov 2020 11:28:56 +0330 > Subject: Re: local read from coordinator > ============ Forwarded message ============ > > > > token-aware policy doesn't work for token range queries (at least in the > Java driver 3.x). You need to force the driver to do the reading using a > specific token as a routing key. Here is Java implementation of the token > range scanning algorithm that Spark uses: > https://github.com/alexott/cassandra-dse-playground/blob/master/driver-1.x/src/main/java/com/datastax/alexott/demos/TokenRangesScan.java > [github.com] > <https://urldefense.com/v3/__https:/github.com/alexott/cassandra-dse-playground/blob/master/driver-1.x/src/main/java/com/datastax/alexott/demos/TokenRangesScan.java__;!!M-nmYVHPHQ!dXosmgU9wrmIw7b4y8Xioii9P_OuSN-mvaCcAKCbdGEzSRBZO20Ibpqoyl9WNDHOVaOupvg$> > > > > I'm not aware if Python driver is able to set routing key explicitly, but > whitelist policy should help > > > > > > > > On Wed, Nov 11, 2020 at 7:03 AM Erick Ramirez <erick.rami...@datastax.com> > wrote: > > Yes, use a token-aware policy so the driver will pick a coordinator where > the token (partition) exists. Cheers! > > > > -- > > With best wishes, Alex Ott > http://alexott.net/ [alexott.net] > <https://urldefense.com/v3/__http:/alexott.net/__;!!M-nmYVHPHQ!dXosmgU9wrmIw7b4y8Xioii9P_OuSN-mvaCcAKCbdGEzSRBZO20Ibpqoyl9WNDHOea1qCGg$> > Twitter: alexott_en (English), alexott (Russian) > > > > > > > > -- > > With best wishes, Alex Ott > http://alexott.net/ [alexott.net] > <https://urldefense.com/v3/__http:/alexott.net/__;!!M-nmYVHPHQ!dXosmgU9wrmIw7b4y8Xioii9P_OuSN-mvaCcAKCbdGEzSRBZO20Ibpqoyl9WNDHOea1qCGg$> > Twitter: alexott_en (English), alexott (Russian) > > > ------------------------------ > > The information in this Internet Email is confidential and may be legally > privileged. It is intended solely for the addressee. Access to this Email > by anyone else is unauthorized. If you are not the intended recipient, any > disclosure, copying, distribution or any action taken or omitted to be > taken in reliance on it, is prohibited and may be unlawful. When addressed > to our clients any opinions or advice contained in this Email are subject > to the terms and conditions expressed in any applicable governing The Home > Depot terms of business or client engagement letter. The Home Depot > disclaims all responsibility and liability for the accuracy and content of > this attachment and for any damages or losses arising from any > inaccuracies, errors, viruses, e.g., worms, trojan horses, etc., or other > items of a destructive nature, which may be contained in this attachment > and shall not be liable for direct, indirect, consequential or special > damages in connection with this e-mail message or its attachment. >
