Once again Erick much appreciate for the reply!
I didn't realise updates forwarded to all NRT replicas for real time gets, I
was under the impression it was eventually. That totally answers my question
and relieves my concerns!
Cheers
Karl
On 31/01/2020, 00:38, "Erick Erickson" <erickerick...@gmail.com> wrote:
I’m not sure it’s worth the effort. Or deterministic for that matter.
First, when you say “get” are you talking about the get request handler
(real time get)? Or a search? Let’s take the two cases separately (and I’m
assuming NRT replicas).
The get request handler: This pulls the most current record whether it’s
been committed or not. So consider an update request. Before it acks back to
the client, the raw document has been forwarded to _all_ replicas and is
available for real time get from any of them. There might be some tiny
advantage in getting it from the leader, but I suspect it’s not really
measurable.
Searching. There’s no guarantee at all that the leader will have the doc
available for searching first due to clock skew for autocommit (and here I’m
assuming you are letting autocommit or commitwithin handle commits, you
should). So say the leader (L) and follower (F) have their autocommit timers
start when they get their first update. At the start, L will start at time T
and Fs timer will start a bit later due to propagation delays. So the wall
clock time for commits well start out different and can continue to skew. If
they get far enough apart, an incoming doc can hit the leader just _after_ the
last commit but hit the follower just _before_ the next commit. So the doc on
the follower can actually return the doc from a search _sooner_ than the leader.
None of that is true about TLOG and PULL replicas however.
This is one of those things I’d recommend you prove is something users
actually could notice before spending any time trying to implement, it strikes
me as a red herring.
Best,
Erick
> On Jan 30, 2020, at 6:16 PM, Karl Stoney
<karl.sto...@autotrader.co.uk.INVALID> wrote:
>
> Hey all,
> Is it possible to perform a get request which favours the current leader,
therefore guaranteeing the most up to date record?
>
> I was looking at shards.preference but couldn’t see a way to prefer the
leader.
>
> Get Outlook for
iOS<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Faka.ms%2Fo0ukef&data=02%7C01%7Ckarl.stoney%40autotrader.co.uk%7C82b562a208e149d0564008d7a5e5e991%7C926f3743f3d24b8a816818cfcbe776fe%7C0%7C0%7C637160279188155081&sdata=AuslYLx3NpsVBcHrijq14rN0jpvzXFMJZNKMcGPYGa4%3D&reserved=0>
> This e-mail is sent on behalf of Auto Trader Group Plc, Registered
Office: 1 Tony Wilson Place, Manchester, Lancashire, M15 4FN (Registered in
England No. 9439967). This email and any files transmitted with it are
confidential and may be legally privileged, and intended solely for the use of
the individual or entity to whom they are addressed. If you have received this
email in error please notify the sender. This email message has been swept for
the presence of computer viruses.
This e-mail is sent on behalf of Auto Trader Group Plc, Registered Office: 1
Tony Wilson Place, Manchester, Lancashire, M15 4FN (Registered in England No.
9439967). This email and any files transmitted with it are confidential and may
be legally privileged, and intended solely for the use of the individual or
entity to whom they are addressed. If you have received this email in error
please notify the sender. This email message has been swept for the presence of
computer viruses.
