Hi Shawn, Thanks for the info. Looking forward to having this functionality in Solr 7.4.0.
Regards, Edwin On 9 June 2018 at 23:02, Shawn Heisey <apa...@elyograg.org> wrote: > On 6/9/2018 8:14 AM, Zheng Lin Edwin Yeo wrote: > >> Just to confirm my understanding, if I have 2 replicas, I should set both >> of them to either NRT replicas or TLOG replicas, and not one of each. >> Then I set one of them to be PULL replica, which will be used for >> searching? >> > > There are multiple possible combinations that will work. My opinion is > that one of these combinations should be used: > > Combo 1: > 2 NRT replicas. > 1 or more PULL replicas. > Set preferred to PULL with SOLR-11982 functionality. > > Combo 2: > 2 TLOG replicas. > 1 or more PULL replicas. > Set preferred to PULL with SOLR-11982 functionality. > > With either of those combos, behavior will be identical no matter which > replica is leader. The second option would have less work to do, but I'm > not sure that it would actually have any better performance than the first > option. > > If you instead choose to have 1 NRT, 1 TLOG, and 1 or more PULL, then > cluster behavior would be different when the NRT replica is leader than it > is when the TLOG replica is leader.It would *work*, though ... and you > might not even notice a difference unless you look closely into how it's > behaving. > > For clarity, keep in mind that a PULL replica cannot become leader. > > Also keep in mind that change visibility with soft commits is only > guaranteed when EVERY replica is NRT. This is mentioned in the > documentation for 7.x versions. > > https://lucene.apache.org/solr/guide/7_3/shards-and-indexing > -data-in-solrcloud.html#combining-replica-types-in-a-cluster > > So if you choose to prefer pull replicas, you will either have to switch > to hard commits for visibility, or live with search results sometimes not > being completely current. > > Thanks, > Shawn > >
