> 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

Reply via email to