* Shard leader elections are not supposed to cause changes to state.json. If it does, it is a bug. I'm sure there is even a test case to test that
* Having the state stored in state.json is not a problem at all bcause it is never updated. It is left there for backcompat reasons Performance and stability improvements are going to be observed only if the cluster is reasonably large. However there is no performance penalty for small clusters On Fri, 3 May 2024, 2:26 am David Smiley, <dsmi...@apache.org> wrote: > In the meetup, my colleague Aparna shared her explorative findings of > enabling PRS, which uncovered 2 matters that seem to defeat much of > PRS's idealized benefits: > * Shard leader elections still touch state.json > * Replica state is still in state.json > Given those two matters, we didn't notice any improvement (or > regression). Some FullStory devs, who use this mode in production, > shared that the first matter wasn't noticed by them because they only > run with one replica per shard. The other... was unclear why; maybe > for backwards-compatibility? In my mind, there shouldn't be such a > concern as it's enabled per-collection and you'd only do this once all > servers are known to be PRS-enabled (e.g. have a modern Solr version). > > If we can identify JIRA issues to capture the work involved, we could > converse more and track the work to completion. I think it's > important to get to a future in Solr 10 where there is one mode (PRS) > not two. > > ~ David Smiley > Apache Lucene/Solr Search Developer > http://www.linkedin.com/in/davidwsmiley > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > For additional commands, e-mail: dev-h...@solr.apache.org > >
