> How about doing your queries against the leader only? This seems to work. We haven't been able to produce an instance where the primary data isn't there in the case where we bound the queries only to the leaders.
> Solr is not transactional. You are assuming ACID properties, > but Solr does not guarantee those, especially cluster-wide. Yeah, understood. Trying to determine if there's a way we could understand if a save + commit + query (optionally to leader) approaches a "transaction", or if that's simply a non-starter given Solr's nature. Kyle On Tue, 7 Sept 2021 at 12:14, Walter Underwood <wun...@wunderwood.org> wrote: > How about doing your queries against the leader only? > > wunder > Walter Underwood > wun...@wunderwood.org > http://observer.wunderwood.org/ (my blog) > > > On Sep 7, 2021, at 9:06 AM, lstusr 5u93n4 <lstusr...@gmail.com> wrote: > > > >> Is there a particular reason for using TLOG replica types? > > > > We used to use NRT replica types, but we switched to TLOG a year or two > ago > > in order to prioritize indexing speed above all else, understanding that > it > > might take a while for query results to be identical across replicas. > This > > is the first time we've had a use case where we need to query immediately > > after indexing. Had we known then what we know now, maybe we wouldn't > have > > switched... but that's hindsight I guess. > > > > With an NRT replica type, do you know if we issue a commit does it apply > to > > all replicas? We're not too far down the path that we couldn't switch > back, > > and I assume that the effect would be minimized if we did so. However, > I'd > > like to know that the issue would be completely GONE, not just reduced in > > frequency if we did switch back... > > > > Thanks! > > > > Kyle > > > > On Fri, 3 Sept 2021 at 13:02, Nick Vladiceanu <vladicean...@gmail.com> > > wrote: > > > >> Is there a particular reason for using TLOG replica types? For such a > >> small cluster and the scenario you’ve described it sounds more > reasonable > >> to use NRT, that will (almost) guarantee that once you write your data - > >> it’ll be (almost) immediately available on all the nodes. > >> > >> > >>> On 3. Sep 2021, at 6:16 PM, Shawn Heisey <apa...@elyograg.org> wrote: > >>> > >>> On 9/3/2021 9:19 AM, lstusr 5u93n4 wrote: > >>>> What we're seeing is the following: > >>>> - index some data > >>>> - issue a hard commit > >>>> - issue a query for that data > >>>> - sometimes the query gets routed to a replica that is not yet > updated, > >>>> and doesn't contain the data. > >>> > >>> How long are you waiting between the hard commit and the query? Are you > >> waiting for the commit operation to return a response before you try to > >> query? I actually don't know whether a commit operation will wait for > all > >> replicas when you're in cloud mode. I don't have a lot of experience > with > >> SolrCloud yet. I did set up a cloud deployment at an old job, but it > was > >> VERY small. All my large-index experience is in standalone mode. > >>> > >>> Commits can sometimes be very slow. This is mostly dependent on your > >> cache autowarm configuration and any manual warming queries that you > have > >> defined. > >>> > >>> Thanks, > >>> Shawn > >>> > >> > >> > >
