Elasticsearch滚动升级步骤

Elasticsearch支持滚动升级，这样就不用停服务，当然只限制特定的版本，特定版本之外的就只能重启整个集群了，在升级的过程中，也许要重建索引。

升级前的注意事项

1. 查看要升级的版本对现在业务的影响
2. 检查弃用日志，关注哪些业务或者查询要在升级之后被弃用
3. 注意插件的兼容性
4. 在开发环境或测试环境试升级
5. 备份数据

新旧版本升级概览

1. 5.x升级到5.y 滚动升级即可
2. 5.6升级到6.x 滚动升级，但是要重建2.x版本的索引
3. 5.0 -5.5升级到6.x 需要重启集群，重建2.x版本的索引
4. 6.x升级到6.y 滚动升级
5. 5.x以下的版本升级到6.x 那就需要重建索引升级了

滚动升级步骤

滚动升级就是es一个节点一个节点的升级，不会影响运行，但是不能同一个集群长时间运行不同版本的节点，那样的话，分区无法复制，es可能会异常。
升级步骤如下：

1. 禁用分片的分配

当我们关掉一个节点时，es默认会等待一分钟（index.unassigned.node_left.delayed_timeout配置项数值），然后开始将当前分片的数据复制到其他节点上，这样做其实为了数据的完整性，毕竟有一个节点挂掉了，总要将数据拿回来。但是这种复制会涉及到大量的IO操作，占用大量的资源，因为es升级其实不需要多长时间，所以这样的复制操作就没有必要，es也是建议先暂时禁用掉这个操作。
操作代码如下：

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

停止不必要的建立索引操作和使用异步刷新

原因很简单，这样做分片恢复的快，整体升级的速度快。
设置异步刷新的时候，要注意返回信息中有没有包含失败信息，如果有，那就继续请求，直到没有失败信息为止。
使用异步刷新代码如下：

POST _flush/synced

暂停有关机器学习的任务

首先要看机器学习的索引是不是在之前的大版本建立的，如果是，那必须要重建索引，并且升级期间不能运行机器学习任务。如果不是，那倒无所谓，停止了一个要升级的节点，任务还可以运行，只不过会跑到其他节点上去并重新获取模型信息，会造成负载高。
可以使用以下api操作任务进入升级状态：

POST _ml/set_upgrade_mode?enabled=true

这样就可以暂时停止与机器学习作业相关的任务，并防止打开新作业。

停止要升级节点上的elasticsearch

采用kill 进程或者sudo systemctl stop elasticsearch.service或者停止服务等方式停止即可。

升级节点

升级节点其实很简单。
首先，如果你的是6.3之前的版本升级到6.3,那么需要删除x-pack插件再升级，因为6.3开始x-pack插件就是已经集成到elasticsearch中了，不需要再安装了。如果你不删除插件就升级，那后面节点肯定起不来，到时候又要降级处理。
然后下载要升级的版本的包或者压缩文件，注意先把配置文件啥的拷出来，如果本来配置文件就不是默认的目录那就不用管了。
最后解压缩升级包，把配置文件和数据文件配置路径全部指向到旧的配置文件目录和数据文件目录。

升级插件

升级你需要的插件。

启动新升级的节点

启动之后通过GET _cat/nodes查看是否已经在集群中。

重启分片分配

重新启用之前禁用的分配设置：

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

然后时不时通过GET _cat/health命令查看状态，等待其正常（升级第一个节点的时候它的状态很可能一直是黄色的，因为就这一个新版本，无法复制分片数据信息，再升级一个节点就能正常恢复绿色了）。
这个命令也可以查看分配的状态：
GET _cat/recovery

重复以上步骤

继续机器学习的任务

之前使用命令使任务变为升级状态的可以恢复：

POST _ml/set_upgrade_mode?enabled=false

总结

滚动升级还是相对比较简单的，只要是保存好配置文件和数据文件，如果不是默认的目录就更好了，免得被误删。期间注意分片得问题和机器学习的问题。