Uploaded image for project: 'Solr'
  1. Solr
  2. SOLR-14942

Reduce leader election time on node shutdown

    XMLWordPrintableJSON

    Details

    • Type: Improvement
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 7.7.3, 8.6.3
    • Fix Version/s: 8.8, main (9.0)
    • Component/s: SolrCloud
    • Labels:
      None

      Description

      The credit for this issue and investigation belongs to Cao Manh Dat. I am merely reporting the issue and creating PRs based on his work.

      The shutdown process waits for all replicas/cores to be closed before removing the election node of the leader. This can take some time due to index flush or merge activities on the leader cores and delays new leaders from being elected.

      This process happens at CoreContainer.shutdown():

      1. zkController.preClose(): remove current node from live_node and change states of all cores in this node to DOWN state. Assuming that the current node hosting a leader of a shard, the shard becomes leaderless after calling this method, since the state of the leader is DOWN now. The leader election process is not triggered for the shard since the election node is still on-hold by the current node.
      2. Waiting for all cores to be loaded (if there are any).
      3. SolrCores.close(): close all cores.
      4. zkController.close(): this is where all ephemeral nodes are removed from ZK which include election nodes created by this node. Therefore other replicas in the shard can take part in the leader election from now.

      Note that CoreContainer.shutdown() is invoked when Jetty/Solr nodes receive SIGTERM signal.

      On receiving SIGTERM, Jetty will also stop accepting new connections and new requests. This is a very important factor, since even if the leader replica is ACTIVE and its node in live_nodes, the shard will be considered as leaderless if no-one can index to that shard. Therefore shards become leaderless as soon as the node (which contains shard’s leader) receives SIGTERM.

      Therefore the longer time step 1, 2 and 3 needed to finish, the longer shards remain leaderless. The time needed for step 3 scales with the number of cores so the more cores a node has, the worse. This time is spent in IndexWriter.close() where the system will

      1. Flush all pending updates to disk
      2. Waiting for all merge finish (this most likely is the meaty part)

      The shutdown process is proposed to changed to:

      1. Wait for all in-flight indexing requests and replication requests to complete
      2. Remove election nodes
      3. Close all replicas/cores

      This ensures that index flush or merges do not block new leader elections anymore.

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                shalin Shalin Shekhar Mangar
                Reporter:
                shalin Shalin Shekhar Mangar
              • Votes:
                0 Vote for this issue
                Watchers:
                4 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:

                  Time Tracking

                  Estimated:
                  Original Estimate - Not Specified
                  Not Specified
                  Remaining:
                  Remaining Estimate - 0h
                  0h
                  Logged:
                  Time Spent - 2h 50m
                  2h 50m