Elasticsearch5.2 版本升级说明

原创
2017/02/06 21:58
阅读数 327

本文翻译官方原文:

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, 此时所有主分片及副本分片已经成功被分配了。

展开阅读全文
打赏
0
2 收藏
分享
加载中
更多评论
打赏
0 评论
2 收藏
0
分享
返回顶部
顶部