> 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'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? Jason On Tue, Jun 27, 2023 at 10:52 PM Shawn Heisey <apa...@elyograg.org> wrote: > > On 6/27/23 15:07, Mikhail Khludnev wrote: > > It handles collection (cloud) as well. But if it's a sharded and replicated > > collection where the healthcheck file will be created? > > In cloud mode the existing ping handler is not very reliable. You might > never know which shard replica is going to actually get the ping > request, and it's only core aware, not collection/shard/replica/node > aware. As a result, it has the same limitations as the DIH handler does > in cloud mode. > > 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. > > I think it's useful as-is for standalone mode, and I would hate to see > it removed unless there is a plan to replace its functionality with > something better. Extending it for cloud mode should involve the > ability to disable health check at the collection level and the node > level, with the health check file probably living in ZK, not on the > disk. Disabling healthcheck would make it so SolrCloud's built-in load > balancing would not use the disabled resource, as well as returning a > non-200 response code from the ping handler or its replacement. > > Thanks, > Shawn > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > For additional commands, e-mail: dev-h...@solr.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org For additional commands, e-mail: dev-h...@solr.apache.org