Is there a JIRA about PRS removal? I'm -1 on this until we prove why it must be removed. PRS introduced because of improved performance and improved stability of cluster operations over the non-PRS mode. Until we prove that there's something better available now, I see no reason why this should be removed.
> Calvin, I recommend that you switch away from PRS and instead in Solr 10 disable the Overseer. In absence of benchmarks, I see no reason to follow your recommendation. My recommendation would be to try out all options available in Solr and use whatever works best for you. > So it's de-facto "experimental" right now and is subject to change... **and removal**. I find no evidence that this is an "experimental" feature. Neither in code, nor in documentation. Can you please point me in the right direction? On Fri, 17 Oct 2025 at 06:57, David Smiley <[email protected]> wrote: > Calvin, I recommend that you switch away from PRS and instead in Solr 10 > disable the Overseer. In doing so, you will continue to have the benefit > of decentralized state updates (a shared characteristic of both > schemes), which is likely desirable for so many replicas you have in > aggregate. You didn't say if you have any large collections (>200 > replicas); if you do then probably don't disable the Overseer yet. > > Thanks for pointing out that line in the ref guide. I propose to the > developer community that I remove that from the ref guide in Solr 10 to > discourage users from enabling a system that is likely to change without > regards to backwards compatibility. > > ~ David > > On Wed, Oct 15, 2025 at 7:01 PM Calvin Smith <[email protected]> > wrote: > > > PRS is documented in the ref guide: > > > > > https://solr.apache.org/guide/solr/latest/deployment-guide/collection-management.html#create-parameters > > > > I know this because I started using it recently (for a new solrcloud > > cluster that I'm working on that will have hundreds of collections), > having > > discovered it through https://searchscale.com/blog/prs/. > > > > I didn't realize that it was experimental and might be removed. > > > > Best, > > Calvin > > > > On Wed, Oct 15, 2025 at 3:23 PM David Smiley <[email protected]> wrote: > > > > > SolrCloud's "PRS" (Per Replica State) mode offers a variation on how > > > replica state is tracked, affecting how state is stored in ZooKeeper > and > > > certainly affecting SolrCloud code. It solves a many-replica > scalability > > > problem of large collections. Coincidentally, that is exactly the > > achilles > > > heel of disabling the Overseer, however PRS didn't go far enough in its > > > approach (IMO) as there is still replica information in state.json. I > > love > > > the conceptual idea / direction of PRS but not the implementation, > which > > is > > > complex -- complexified further by being bolted onto the existing code > > > instead of green-field. If we are to imagine making any serious > > > improvements like this to how a collection's state is structured in > > > ZooKeeper, I can't imagine realistically doing such work with PRS > > > existing. I think such work would start with removing PRS without > > > concern/burden of compatibility. > > > > > > Thankfully, PRS is rather invisible to our users -- it's not documented > > in > > > the ref guide. I think only Full Story is using it. So it's de > > > facto "experimental" right now and is subject to change... **and > > removal**. > > > > > > FWIW I'd love to help design its replacement, but that's not the > subject > > of > > > this post/thread. > > > > > > ~ David Smiley > > > Apache Lucene/Solr Search Developer > > > http://www.linkedin.com/in/davidwsmiley > > > > > >
