Three nodes with nginx in front will handle well over 50k searches a day on a half terabyte index, but only one node is to serve the searches the rest are backups. I would never put solr in a container
> On Jul 17, 2022, at 10:44 AM, Shawn Heisey <apa...@elyograg.org> wrote: > > On 7/17/22 07:40, Ronen Nussbaum wrote: >> We are planning to migrate our Solr Cloud clusters to the cloud. >> Currently it is installed on-prem for each customer. >> It is already deployed as Docker containers. >> Instead of estimating in advance what is the number of shards needed, or >> the number of pods, we'd like to rely on EKS cluster autoscaler, K8S HPA >> and Solr autoscaling. >> Our main concern is the deprecation of the autoscaling feature since >> version 9.0. > > One thing I am not sure you're aware of: You can't add shards to a > collection unless it is using the implicit router, which is poorly named > because what it means is that sharding is 100% user-managed (manual). > > There is the shard splitting capability in the Collections API, but that only > works on a single shard, not the whole collection. If you wanted to adjust > from say 6 to 8 shards and still have the shards be approximately equal in > size, you would need to build a new collection and completely reindex. > > There have been a number of issues filed for a rebalance feature, but it has > not been implemented because implementing it would involve a very large > amount of work, and making it stable would take even more work. And I am not > even sure the Lucene API has the capability to do it currently. > > https://issues.apache.org/jira/browse/SOLR-9241 > >> What is your recommendation? Should we start with 8.11? Will it be a >> substitute soon? > > I have no idea whether a substitute will be available. You can manually do > everything that the autoscaler would do with the Collections API. > > Thanks, > Shawn >
