Elasticsearch:Restart a cluster or node

Pre-restart checks

Complete the following checks before restarting.

1. Check the cluster health status
   Connect to the cluster through Kibana and run GET _cluster/health. Verify that status is green.

   Exception: Forced restart is available only when status is yellow or red.

2. Ensure data redundancy
   Run GET _cat/indices?v to check the rep (replica count) for all critical indices.

   • Replica count must be at least 1. Indices without replicas become inaccessible during restart.

   • For multi-zone instances, replica count must be less than the zone count.

3. Check and handle closed indices
   Run GET _cat/indices?v to check for indices with status = close.

   • Closed indices block shard allocation and the restart process.

   • To open closed indices, run POST /<index_name>/_open.

4. Assess cluster load
   On the Cluster Monitoring page, verify resource usage allows sufficient capacity for shard migration:

   • Node CPU Utilization: below 80%

   • Node Heap Memory Usage: around 50%

   • NodeLoad_1m: below the CPU core count

Procedure

After completing health checks, restart the cluster:

1. Log on to the Alibaba Cloud Elasticsearch console. In the left navigation pane, click Elasticsearch Clusters.

2. Select the region of the target instance in the top menu bar. Click the instance ID, and click Restart in the upper-right corner of the Basic Information page.

   

3. In the Restart dialog box, configure the parameters:

   

   • Object

     • Cluster: Restarts all nodes in the cluster. Suitable for cluster-level changes.

     • Node Restart: Restarts one or more specified nodes. Suitable for resolving issues with individual nodes.

     • Node Role (For basic control v2 architecture only): Restarts nodes of a specific role that you select, such as data nodes or Kibana nodes.

   • Blue-green Update and Restart Mode

     Select a restart method based on your scenario, cluster status, and risk tolerance:

     Restart method	Required Cluster Status	Mechanism and scenario	Impact	Limitations
     Blue-green Update	Normal (green)	Adds new nodes, migrates data from old nodes to new nodes, then removes the old nodes. Suitable when a node has persistent high CPU usage and you prioritize availability over change duration. Important A blue-green update cannot be used with a forced restart.	Node IP addresses change. Cluster performance may briefly fluctuate.	Not supported for 1 vCPU 2 GB cluster specs
     Restart (Standard)	Normal (green)	Planned maintenance and regular cluster configuration.	This method doesn't change node IP addresses and takes longer. Service remains available with replica shards, but may briefly fluctuate.
     Phased Restart	Normal (green)	Verifies restart effects in batches to reduce production risks. Select nodes for the first batch. After the cluster stabilizes, manually trigger the restart of remaining nodes.	This method doesn't change node IP addresses and minimizes impact on production.	Available for cloud-native control architecture (v3) clusters only
     Forced Restart	Abnormal (yellow/red)	Suitable when the cluster is in an unhealthy state (yellow or red). Other restart methods are disabled.	This method doesn't change node IP addresses. Higher concurrency speeds up restart but increases risk: 100% concurrency restarts all nodes simultaneously, causing service interruption and potential loss of unpersisted cached data. Use high concurrency only for urgent recovery of abnormal clusters. Concurrency: Percentage of nodes restarted simultaneously. Default is 10%, minimum 1 node. Displayed only in forced restart mode.

4. (Optional) For forced restart, select Restart Cluster Forcibly.

5. Click OK.

   The cluster status changes to Initializing. Status returns to Normal after completion.

Post-restart verification

Verify cluster health and monitor shard recovery after restart:

1. Check cluster health:

   GET _cluster/health

2. Monitor nodes and shard recovery:

   GET _cat/nodes
   GET _cat/recovery

3. Wait for all shards to be allocated before resuming normal operations.

FAQ

• How long does it take to restart an ES instance or node?

• Does enabling or disabling public network access for an ES instance trigger a restart?

• Does changing the cluster access password trigger a cluster restart?

• Does the absence of replica shards in an index affect a cluster restart?

• How do I restart a role node (such as a Kibana node) or a single node?