共计 1843 个字符，预计需要花费 5 分钟才能阅读完成。
本篇文章给大家分享的是有关 Elasticsearch 集群版本升级步骤及注意事项是什么，丸趣 TV 小编觉得挺实用的，因此分享给大家学习，希望大家阅读完这篇文章后可以有所收获，话不多说，跟着丸趣 TV 小编一起来看看吧。
1、升级前的准备工作
从 Elasticsearch 的官方网站 https://www.elastic.co/downloads/elasticsearch 下载最新版本的 Elasticsearch，为了线上方便对数据包的管理，一版选择 .gz.tar 格式或者 .zip 格式文件。
解压缩最新版本文件压缩包到指定目录，备份 config 目录中的 elasticsearch.yml 文件（可以简单更名，为 elasticsearch.yml.bak 即可）。然后复制当前版本 Elasticsearch 中配置文件 elasticsearch.yml 文件的内容，到最新版本的 config 目录中。
检查系统中 Java 环境是否正常，目前 Elasticsearch 的版本必须使用 Java 1.7.0 及以上版本才能正常启动 Elasticsearch。
修改 bin 目录中 elasticsearch.in.sh 文件，关于 Elasticsearch JVM 内存配置大小：
这个值可以根据需要适当的调整的更大。如此，当 Elasticsearch 中存在很多 index 的时候不会出现 Too many open files 的错误：
如果看到了以上内容，则表明新版本的 Elasticsearch 可以正常运行。接下来，就准备更换节点 ES 版本了。
2、集群滚动升级
滚动升级（Rolling upgrade）
Rolling upgrade 的备份过程可以让用户在一个时间内只升级集群中的某一个特定的节点。由于 Elasticsearch 集群具有非常优秀的容灾机制，因此，在删除集群中的某一个节点时，数据并不会丢失，而是可以由其余节点上的拷贝恢复。
不建议在一个集群中长时间的运行多个版本的 Elasticsearch 实例，因为当删除的节点恢复时，将来自多个版本实例的数据汇聚到同一个节点会有可能会导致节点无法工作。
接下来来叙述 Rolling upgrade 升级的操作步骤：
关闭 shard 的实时分配选项，这样做的目的在于当集群 shutdown 之后可以快速的启动。这个参数默认是开启的，默认情况下当实例启动时，会尝试从其他节点实例上拷贝相关的 shard 副本至本地，这样会浪费大量的时间和耗费高额的 IO 资源。如果实时分配选项关闭了，那么当新的实例启动，尝试加入集群的时候，它不会从其他实例上拷贝 shard 副本。当实例完全启动之后，则应该再将该选项开启，以提供长期的容灾。
curl -XPUT localhost:9200/_cluster/settings -d {
transient : { cluster.routing.allocation.enable : none
}
}关闭所要升级版本的节点实例，并将其移除集群
curl -XPOST http://localhost:9200/_cluster/nodes/_local/_shutdown移除节点之后，等待剩余节点数据转移完成，直到确定所有的 shard 都被正确地分配。
升级节点的 Elasticsearch 版本，最简单和最安全的办法就是下载一个全新的 Elasticsearch 版本到本地，并将原来 Elasticsearch 的配置文件复制到新的版本中，最好能建立一个 Elasticsearch 的软连接到最新版本文件所在的目录，这样可以方便将来使用。
启动已经升级好的节点 ES 实例，并检查其是否正确地加入到集群中。
重新开启 shard reallocation 选项（实时分配选项）
curl -XPUT localhost:9200/_cluster/settings -d {
transient : { cluster.routing.allocation.enable : all
}
}检查所有的 shard 是否正确地被分配，并观察集群是否有执行负载均衡（也是就说每个节点被分配相等数目的 shard）
重复以上过程至集群中的每个节点，直至这个集群中所有节点完成版本升级。
以上就是 Elasticsearch 集群版本升级步骤及注意事项是什么，丸趣 TV 小编相信有部分知识点可能是我们日常工作会见到或用到的。希望你能通过这篇文章学到更多知识。更多详情敬请关注丸趣 TV 行业资讯频道。
