Elasticsearch 集群版本升级步骤及注意事项

一、升级前的准备工做

• 从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 内存配置大小：

　　        

        此处能够根据机器硬件配置状况做出适当的调整，通常状况下，此处的内存分配大小为机器物理内存的一半，同时将 ES_MIN_MEM 与 ES_MAX_MEM 配置成相同的值，这样的好处在于ES JVM大小固定，不会上下浮动，从实践效果上看能够提升 node 性能。

 

• 检查系统容许 Elasticsearch 打开的最大文件数

        查看 /etc/security/limits.conf，若是没有指定的话，默认是4096。这里应该添加以下两行：

　　        

        这个值能够根据须要适当的调整的更大。如此，当 Elasticsearch 中存在不少 index 的时候不会出现 Too many open files 的错误：

        

        

• 此外，因为ES集群通常都是在内部网络环境中，且节点之间相互通讯使用的是 TCP 9300端口，节点与客户端通讯则是经过 TCP 9200端口。所以检查 iptalbes 以及SElinux 中是否开启，以及肯定这些端口是否被绑定安全策略等等。

 

• 数据备份

        在进行升级以前，咱们首先要作的就是备份好目前系统中已经存在数据，防止在升级的过程当中出现问题后能够方便的恢复原有的数据。例如，在升级的过程当中，若是版本差异过大，可能会涉及到底层Lucene libraries的升级，这必将会影响到已存在的index数据，有时升级后的节点没法加入原有版本的集群中。

        幸运的是Elasitcsearch的备份工做十分的简单，备份将用到Elasticsearch的snapshot功能，关于备份和恢复的详细过程我会单独详细阐述。

 

• 若是有必要的话，能够在最后的上线以前能够再作一次最后的测试，在测试以前，先修改Elasticsearch 中的配置文件，便是elasticsearch.yml 中的 cluster.name 参数的名称，避免加入了线上集群中。并利用 curl -XGET localhost:9201 来测试新版本的 Elasticsearch 进程是否正常。　　

　　curl -XGET localhost:9200

　　        

        若是看到了以上内容，则代表新版本的Elasticsearch 能够正常运行。接下来，就准备更换节点ES版本了。

 

 

二、集群滚动升级

• 滚动升级（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的版本都逐渐成熟，曾经的遗留版本基本上不多见到了，所以从1.0版本以前升级到1.0版本以后的步骤就不一一说明了，这个过程将不得不重启整个集群系统才能完成整个版本升级的过程，这里再也不详细阐述，若有兴趣可参看：https://www.elastic.co/guide/en/elasticsearch/reference/current/setup-upgrade.html 

 

目前暂时总结这么多了，未来会持续更新。