ES滚动升级方案

前言

为了修复 Log4j 的漏洞，采用升级ES版本的方式解决问题，整个过程为滚动升级不会影响到线上的正常使用。

---

一、升级版本

旧版本：V7.8.1

新版本：V7.16.2，修复Log4j方式为升级log4j jar到v2.17.0

二、准备工作

1.环境搭建

在目标主机上准备好ES V7.16.2的环境配置工作，准备完成后等待滚动重启。

2.查看分片

找出集群中只有一个shard的Index，避免滚动升级时数据丢失，如果该index存储的消息不重要可忽略，反之当更新到当前node时需要将该shard迁移到其它node上去。

GET /_cat/shards?v

index：索引名称
shard：分片数
prirep：分片类型，p：primary为主分片，r：replicas为复制分片
state：分片状态，STARTED为正常分片，INITIALIZING为异常分片
docs：记录数
store：存储大小
ip：es节点ip
node：es节点名称

---

三、滚动升级

1.禁用分片分配

升级集群，没有必要让节点上的 shard 进行 reallocation，避免 IO。设置只允许 新 index 的主分片分配。

PUT _cluster/settings
{
  "persistent": {
    "cluster.routing.allocation.enable": "new_primaries"
  }
}
 
all - 默认的，允许所有shards分配
primaries - 只允许主分片分配
new_primaries - 只允许新index的主分片分配
none - 所有的都不允许

2.禁止同步更新。

停止非必要的索引并执行synced-flush，分片恢复会快得多 。

POST _flush/synced

3.迁移数据

迁移目标node上的index数据到新的node上去，避免数据丢失

1：关闭ES rebalance，停止当前Node上的shard被均衡到其他机器上，避免造成不必要的IO
PUT _cluster/settings?pretty
{
  "transient" : {
    "cluster.routing.rebalance.enable" : "none"
  }
}

2：迁移数据，通过下列命令将指定的 index 迁移到指定 Node，等待当前Node上的单副本 index 都迁移完成后再停止Node
PUT ${indexName}/_settings
{
    "index.routing.allocation.exclude._ip": "xxx.xxx.xxx.xxx" //当前需要升级的Node ip
}

3：查看数据迁移进度
GET _cat/shards/${indexName}?v&s=ip:asc

4.更新节点

根据各自的部署方式来停止旧的节点，启动新的节点 ，最后查看新节点是否加入集群。

GET _cat/nodes

5.重启分片分配

节点加入集群后，设置重新启用分片分配并开始使用该节点

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

 6.等待节点恢复

1：在升级下一个节点之前，请等待集群完成分片分配。您可以通过提交_cat/health请求来检查进度,直到集群恢复green,这个过程根据分片数量的多少，需要消耗一定的时间
GET _cat/health?v
 
2：未同步刷新的碎片可能需要更长的时间才能恢复。您可以通过提交_cat/recovery请求来监视各个分片的恢复状态
GET _cat/recovery

 6.重复滚动更新

当节点恢复并且集群稳定后，对每个需要更新的节点重复这些步骤。_cat/health您可以通过请求监控集群的运行状况