On 8/1/23 13:35, Jason Gerlowski wrote:
At one time I had an install that used the ping handler to tell haproxy
which replicas (not using cloud OR /replication) were down either
because of problems or because I wanted to explicitly take it out of
rotation. It worked really well for that.
Curious - did you move away from this for a different approach? Or
did the deployment itself change and make the /ping+haproxy
combination unnecessary?
I was laid off from that job in 2018. I don't know what they did with
it after I left.
I'm likely missing something, but that use case seems like something
that's already covered reasonably well by the "LoadBalancing" line of
SolrClients. LB clients keep a "dynamic" record of server health
(based on previous requests/responses), and also allow users to
manually add/remove servers from rotation. So at a glance at least it
covers the key pieces of the /ping+haproxy use case?
Do the LB clients offer the option of saying "take index copy A out of
rotation" without touching the application? I can't imagine that would
be possible. That was trivially easy with a status page that I
developed for the Solr install as a whole -- it had a link where I could
do "disable" or "enable" on the ping handler for each copy of the index.
The clients in the applications had no need to be aware of multiple
copies of the index, because the load balancer handled all of that.
I had haproxy set up to use only copy A if it was available (and enabled
in the ping handler), and move to copy B if not, and last ditch was copy
C, my dev install. I could have also had it use both copy A and B, but
active/backup seemed like a better option.
Upgrades were pretty easy with that setup. I could upgrade copy B
(including a full reindex), then disable the ping handler for copy A,
and upgrade/reindex copy A. If I needed to test a config change, I
could do the change on copy B or C, without affecting the live index on
copy A. All without SolrCloud. I did have some ideas for switching to
cloud, but it would have required a substantial rewrite of the indexing
system. If I was still working there, I very likely would have done so
by now.
Thanks,
Shawn
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
For additional commands, e-mail: dev-h...@solr.apache.org