Elasticsearch5.2 版本升级说明

本文翻译官方原文：

https://www.elastic.co/guide/en/elasticsearch/reference/5.2/restart-upgrade.html

实际比较中，在前面版本的ES升级基本也遵循这个升级方案，这个方案是集群重启升级方案。
Elasticsearch Reference [5.2] » Setup Elasticsearch » Upgrading Elasticsearch » Full cluster restart upgrade

集群整体重启升级

当跨主版本升级的时候，Elasticsearch 需要整个集群重启。主要版本升级不支持滚动升级。你可以查询这个表格，来确认是否需要重启整个集群。

使用集群重启Full cluster restart来执行程序升级的步骤如下：

1、关闭分配分片功能

    当你关闭一个节点的时候， 分配程序会立即尝试复制这个节点上的分片，到集群的其他节点上去，这也成为消耗I/O的原因之一。但这也可以通过在关闭（node节点）之前，关闭分配功能来避免。

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

 

2、执行同步刷新synced-flush

当你停止数据索引并且使用同步刷新请求的时候，分片恢复将会更加快速。

POST _flush/synced

同步刷新请求是“最大努力”操作。只要有任何索引操作，同步刷新都会失败，但在必要的情况下，重新发布请求多次，也是安全的。

 

3、关闭并且升级所有节点

关闭集群中所有节点的Elasticsearch服务。 每一个节点都可以通过相同的步骤来完成升级操作，升级步骤在【升级节点】。

翻译自：

https://www.elastic.co/guide/en/elasticsearch/reference/5.2/rolling-upgrades.html#upgrade-node

升级之前先关闭集群的节点。
    提示：

      当使用zip包或者tarball包，config, data, logs and plugins目录被默认放在了Elasticsearch根目录.
      如果把这些目录放在一个不同的位置实际是一个非常不错的主意，这样子在升级ES的时候，就不会删除这些数据了。这些定制路径可以在path.conf, path.logs, and path.data 里面设置，同时使用 ES_JVM_OPTIONS配置来指定本地的jvm.options配置。
       Debian系统以及RPM包为每种操作系统将这些目录放到了合适的位置。
使用Debian包或者RPM包升级：

•     使用rpm或者dpkg，安装新的包。所有文件需要被放在本地路径，并且配置文件不得被覆盖。

使用zip或者压缩tar包升级：

•     将zip包或者tar包放到一个新的路径，并且确认不会覆盖你的配置文件和数据文件的路径。
•     从老的安装文件中，将config路径下的所有文件复制到新的安装路径中；或者将jvm.options文件的环境变量ES_JVM_OPTIONS设置为本地，并且在命令行中使用 -E path.conf= 命令，指定为外部配置目录。
•     复制data目录，从原来的安装目录到新的安装目录，或者在config/elasticsearch.yml中设置path.data，来配置本地的数据目录。

4、升级所有组件

升级节点的时候，Elasticsearch组件必须升级。你可以使用elasticsearch-plugin脚本安装你需要的所有插件的正确版本。

 

5、开启集群

如果你有专用的主节点（node.master 设置为true，并且node.data 设置为false ），那最好就先启动他们。 在开启数据节点之前，先等待他们被选为主节点。你可以通过实时查看logs日志，来检查程序进行的阶段。

一旦最少个数具备主节点权限的节点发现了彼此，他们就会从集群中选择出主节点了。 这个时候 _cat/health 以及 _cat/nodes APIs监控加入集群的节点:

GET _cat/health  
GET _cat/nodes

[root@webapp1 ~]# curl -XGET 'http://192.168.61.189:9200/_cat/health' 
1486388923 21:48:43 jsdx-cluster-01 green 4 3 462 231 0 0 0 0 - 100.0% 

[root@webapp1 ~]# curl -XGET 'http://192.168.61.189:9200/_cat/nodes'
192.168.61.189 192.168.61.189  5 23 0.00 - m node0 
192.168.61.190 192.168.61.190 36 73 0.12 d - node1 
192.168.61.193 192.168.61.193 58 69 0.18 d - node3 
192.168.61.192 192.168.61.192 53 71 0.61 d * node2 

使用这个APIs检查所有节点是否已经加入了集群。

 

6、等待状态变为黄色

一旦所有节点均加入了集群，集群将开始恢复所有本地存储的主分片。首先 _cat/health 将会报告status 状态信息是： red,这意味着所有的主分片没有分配完毕。.

当所有节点都回复了本地的分片，状态status就会变成yellow状态了,这意味着所有主分片都被恢复了， 但并不是所有的副本分片 replica shards 都被分配好了。这是预料之中的，因为分配功能还不可用。

 

7、恢复分配allocation 功能

延迟Delaying 分配副本,直到所有节点加入了集群，这样子允许主节点分配副本到那些有本地碎片副本的节点上。至此，所有节点已经加入集群，开启分片分配功能，就是安全的了:（第一步关掉了分配功能）

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

现在，集群将会分配所有副本分片到各个数据节点当中。 至此，重新开启索引及查询功能就是安全的了，但是如果你延迟恢复索引及搜索功能指导所有分片都恢复好了，集群会恢复的更快。

你可以使用： _cat/health and _cat/recovery APIs:

GET _cat/health
GET _cat/recovery   

[root@webapp1 ~]#    curl -XGET 'http://192.168.61.189:9200/_cat/recovery'
ywsoc-penetration           0 176  replica    done 192.168.61.190 192.168.61.192 n/a n/a 16 100.0% 47190   100.0% 16 47190   0  100.0% 0  
ywsoc-penetration           0 35   store      done 192.168.61.190 192.168.61.190 n/a n/a 0  0.0%   0       0.0%   0  0       0  100.0% 0  
ywsoc-penetration           1 16   store      done 192.168.61.192 192.168.61.192 n/a n/a 0  0.0%   0       0.0%   0  0       0  100.0% 0  
ywsoc-penetration           1 145  replica    done 192.168.61.192 192.168.61.193 n/a n/a 25 100.0% 86714   100.0% 25 86714   0  100.0% 0  
ywsoc-penetration           2 35   replica    done 192.168.61.193 192.168.61.192 n/a n/a 1  100.0% 130     100.0% 1  130     0  100.0% 0  
ywsoc-penetration           2 40  

直到_cat/health 命令的status列输出为green, 此时所有主分片及副本分片已经成功被分配了。

转载于:https://my.oschina.net/yangertt2006/blog/832934