Elasticsearch 3节点集群缩容至1节点：无停机方案及风险咨询

Hey there, let's break down how to gracefully scale your 3-node Elasticsearch 5.6.8 cluster down to 1 node without downtime, plus cover the key consequences you need to plan for.

First, let's make sure we don't leave any unassigned shards or cause downtime during the process:

1. Set all index replicas to 0
   Since a single node can't host replica shards (there's no other node to put them on), we need to disable replicas for every index first. Run this command:

   PUT _all/_settings
   {
     "number_of_replicas": 0
   }
   

   Wait until all shards show as STARTED when you run GET _cat/shards?v—no UNASSIGNED entries should remain. This ensures all data is only stored on primary shards, which we'll soon consolidate onto your remaining node.

2. Exclude the two nodes from shard allocation
   Tell Elasticsearch not to assign any shards to the nodes you're removing, and to migrate existing shards off them to your keep node. Use the IP addresses (or node names, if you prefer) of the two nodes you want to remove:

   PUT _cluster/settings
   {
     "persistent": {
       "cluster.routing.allocation.exclude._ip": "192.168.1.10,192.168.1.11"
     }
   }
   

   Keep checking GET _cat/shards?v until all primary shards are running on your remaining node, and the two target nodes have no shards left. This migration happens in the background without taking your cluster offline.

3. Shut down the two nodes
   Once all shards are safely migrated, you can stop the Elasticsearch service on the two nodes—no data will be lost at this point.

4. Clean up the allocation exclusion setting
   Remove the exclude rule so future node additions (if any) work correctly:

   PUT _cluster/settings
   {
     "persistent": {
       "cluster.routing.allocation.exclude._ip": null
     }
   }
   

Before you make this change, be fully aware of the tradeoffs:

• Total loss of high availability: If your single node crashes, loses power, or has a disk failure, your entire cluster goes down and you'll lose access to your data unless you have a recent snapshot backup. There's no redundancy to fall back on.
• Performance bottlenecks: All read/write traffic will hit this one node. Expect slower query response times and reduced indexing throughput, especially under high load.
• No replica safety: You can't enable replicas anymore (they'll just sit as unassigned shards), so your data only exists in one place. Any accidental data deletion or corruption can't be recovered from a replica.
• Higher cluster state risk: A single node is more vulnerable to issues like excessive GC, memory pressure, or disk space shortages. Any of these can quickly push the cluster into a red state, making data inaccessible.
• Backup becomes critical: You must set up regular snapshot backups (to a remote storage like local network storage, cloud object storage, etc.) to mitigate data loss risk. Without backups, you're one failure away from losing all your data.

• Take a snapshot first: Before starting any cluster changes, create a full snapshot of your cluster. This is your safety net if something goes wrong during migration.
• Check resource capacity: Ensure your remaining node has enough disk space (at least 1.5x the total size of all your data to account for temporary files and future growth) and sufficient CPU/memory to handle the full load.
• Consider upgrading later: Elasticsearch 5.6.8 is quite old (end-of-life since 2019) and has known security vulnerabilities and bugs. If possible, plan an upgrade to a supported version after stabilizing the single-node cluster.

内容的提问来源于stack exchange，提问作者Mohammad Saifullah