2设置--6更新es

更新之前一定要备份数据。可以使用一些插件差检测潜在的问题。
滚动升级
es集群准许一台一台的升级并且对用户无影响。多版本的es不支持此种情况，因为新版本的数据分片不能被老版本识别。
第一步 禁止发数据分片分配
当你关闭一个节点的时候，在复制本节点数据到集群中之前，分配节点会等待一分钟。这会造成大量无用io。如果想避免这种情况，在关闭节点之前执行

PUT _cluster/settings
{
  "transient": {
    "cluster.routing.allocation.enable": "none"
  }
}

第二步 停止不重要的索引并且执行同步（可选）
可能大家都很希望边升级边进行数据索引（正常工作），但是如果能够暂时工作然后发送一个同步的请求这样会更快些。

POST _flush/synced

如果有新的数据进行更改，请求会失败，可以进行多次请求确保成功。
第三步
停止其中一个节点，然后进行升级。此处建议config，data，log，plugins这四个文件夹存放在不同地方，这样升级的时候就避免了被覆盖
第四步
更新插件
使用

elasticsearch-plugin

脚本安装正确版本的插件
第五步
启动更新了的节点
启动节点，确认加入了集群。（根据日志方式查看，或者查看

GET _cat/nodes

）
第六步
重新启动分片分配
一旦加入了集群成功则执行如下操作启用数据分配

PUT _cluster/settings
{
  "transient": {
    "cluster.routing.allocation.enable": "all"
  }
}

第七步
等待节点恢复
确认数据同步完成

GET _cat/health?v

，然后更新下一个节点
查看状态由yellow变为green。此处需要注意，如果主节点的版本较新，则他不会有数据备份，因为新版本的es可能会有更新的数据格式。这种情况下查看init字段和replo列都为0.当下一个节点更新完之后，状态就应该变为green了。
节点需要一些时间进行恢复可以通过

GET _cat/recovery

来查看恢复情况。
第八步
上面都成功了，重复进行上面的操作

集群重启升级
当es具有大版本的升级的时候，只能进行整个集群重启。

第一步
禁止数据分片的数据分配

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

第二步
执行同步

POST _flush/synced

第三步
停止es并且更新所有节点
第四步
更新插件
使用

elasticsearch-plugin

脚本更新所有插件
第五步
启动集群

GET _cat/health

GET _cat/nodes

查看集群状态
第六步
当所有的节点都加入了集群，则可以通过

_cat/health

查看当前节的数据碎片状态。当显示为黄色（yellow）说明所有主节点已经准备ok了。
第七步
开始数据碎片的同步分配

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

这个时候可以查看数据同步情况

GET _cat/health
GET _cat/recovery

一旦在健康状态中为绿色（green）则说明成功