Package org.apache.solr.handler.admin

Class HealthCheckHandler

java.lang.Object
org.apache.solr.handler.RequestHandlerBase
org.apache.solr.handler.admin.HealthCheckHandler
All Implemented Interfaces:
AutoCloseable, ApiSupport, SolrInfoBean, NestedRequestHandler, SolrMetricProducer, SolrRequestHandler, PermissionNameProvider
public class HealthCheckHandler extends RequestHandlerBase
Health Check Handler for reporting the health of a specific node.

For the Solr Cloud mode by default the handler returns status 200 OK if all checks succeed, else it returns status 503 UNAVAILABLE:

  1. Cores container is active.
  2. Node connected to zookeeper.
  3. Node listed in live_nodes in zookeeper.

The handler takes an optional request parameter requireHealthyCores=true which will also require that all local cores that are part of an active shard are done initializing, i.e. not in states RECOVERING or DOWN. This parameter is designed to help during rolling restarts, to make sure each node is fully initialized and stable before proceeding with restarting the next node, and thus reduce the risk of restarting the last live replica of a shard.

For the legacy mode the handler returns status 200 OK if all the cores configured as follower have successfully replicated index from their respective leader after startup. Note that this is a weak check i.e. once a follower has caught up with the leader the health check will keep reporting 200 OK even if the follower starts lagging behind. You should specify the acceptable generation lag follower should be with respect to its leader using the maxGenerationLag=<max_generation_lag> request parameter. If maxGenerationLag is not provided then health check would simply return OK.