记一次ES生产集群数据节点扩容的操作过程

一、前言--客户需求

客户自建ES集群，集群版本是6.8.1，由于生产需要将集群的3个节点进行升级配置。但是不能影响现有业务。

二、升级方案

正常情况下，Elasticsearch 希望用户的数据被完全的复制和均衡的分布。如果用户手动关闭了一个节点，集群会立刻发现节点丢失并开始集群分片的再平衡，就会出现节点间分片的均衡，这对于生产集群来说无疑是影响读写业务以及耗费集群资源的。由于本次节点升配时间不长，采用节点滚动升级的方式，升级一个节点完毕，等集群green再升级另外的第二个节点，以降低对业务的最大影响。因此，我们决定采用如下的方式进行集群的节点升级，步骤如下：

1. 建议用户停止索引新的数据，这可以帮助提高集群的恢复速度。
2. 阻止 Elasticsearch 再次平衡缺失的分片，因为大型分片的再平衡需要花费相当的时间，影响集群变更。<这点尤为重要>

PUT /_cluster/settings
{
    "transient" : {
        "cluster.routing.allocation.enable" : "none"      //取消分片权衡
    }
}

3. 关闭要升级的单个节点，步骤：停掉ES进程，然后关机，进行配置升级。

4. 执行节点维护/升级。

5. 重启节点，然后确认它加入到集群了。

6. 用如下命令重启分片分配：

PUT /_cluster/settings
{
    "transient" : {
        "cluster.routing.allocation.enable" : "all"       //恢复分片权衡
    } 
}

or

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

这个时候集群状态为“YELLOW”，大约数分钟后，集群Green.

7. 重复第 2 到 6 步操作剩余节点升级。每次节点操作完毕，集群都会有几分钟的Yellow。

8. 恢复业务索引写入。

9. 随后，按照客户的要求，将相关的业务索引，指定到升级配置的节点。使用如下：

PUT index_name/_settings
{
  "index.routing.allocation.include._ip": "10.124.105.5,10.124.105.6,10.124.105.7"
}
//include   表示OR的意思

三、总结

本次我们采用上面的方式给用户进行生产集群的节点升级。整个操作过程大概耗时在40分钟左右，调整了ES集群的节点配置，配置文件的变更等操作，顺利完成了客户的集群变更的保驾护航操作。滚动重启的方式适合于Elasticsearch 版本升级，或者服务器自身的一些维护操作（比如操作系统升级或者硬件相关）。希望大家可以借鉴一下。

当然，我们也考虑将节点exclude的方式进行滚动升级，比如如下API，但是这个API会在将节点下线前，将上面的分片全部挪到其它节点。时间比较长，故不予考虑。

PUT _cluster/settings
{
  "transient" : {
    "cluster.routing.allocation.exclude._ip" : "10.0.0.1"
  }
}