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 > > >
