Elasticsearch 自从1.0.7版本之后，集群各节点的滚动式升级已不需要重启集群，相比之前的升级模式来看，可以非常平滑的渡过升级过程。这里将叙述集群滚动式升级及其注意事项。

 

1、升级前的准备工作

• 从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版本了。

 

 

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的版本都逐渐成熟，曾经的遗留版本基本上很少见到了，因此从1.0版本之前升级到1.0版本之后的步骤就不一一说明了，这个过程将不得不重启整个集群系统才能完成整个版本升级的过程，这里不再详细阐述，如有兴趣可参看： 

 

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