I’ve never understood paying for “cold” backup machines that don’t take 
traffic. Keep them all hot. That way you know they work and you don’t have cold 
cache slow startup problems when you put them into service.

Yes, agree about containers. Containers are great for CPU-only applications. 
They just aren’t designed for persistent data.

wunder
Walter Underwood
wun...@wunderwood.org
http://observer.wunderwood.org/  (my blog)

> On Jul 17, 2022, at 7:58 AM, Dave <hastings.recurs...@gmail.com> wrote:
> 
> 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
>> 

Reply via email to