滚动升级
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）则说明成功