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://aka.ms/o0ukef> > 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.
