Elastic Search升级方法论
Elastic Search升级方法论
shawnplaying 发表于1年前
Elastic Search升级方法论
  • 发表于 1年前
  • 阅读 37
  • 收藏 0
  • 点赞 0
  • 评论 0

【腾讯云】新注册用户域名抢购1元起>>>   

摘要: elastic earch, logstash, kibana 升级

Rolling upgrade

针对cluster,逐一升级每个节点,整个系统对用户可用。不支持大版本major version升级,只能在小版本升级时使用。

升级中新版本的节点是不能向旧版本的节点做shard replication,所以不能长时间运行一套包含不同版本节点的cluster环境。

参考:https://www.elastic.co/guide/en/elasticsearch/reference/current/rolling-upgrades.html

1 禁止shard allocation。

当关闭一个节点是,allocation process将会等待一分钟,然后再做shard allocation操作。这个操作可以通过命令来避免。

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

2 停止non-essential indexing并且做synced flush操作。

如果想要indexing操作变快,可以停止non-essential indexing并且做synced flush操作。

POST _flush/synced

一个synced flush请求是一个best effort操作。如果有任何indexing操作,那么可以重复做sysnced flush操作,它对我们来说是安全的。

3 停止和升级单个节点。

首先停止集群中一个节点。然后升级它。

针对每个节点,有几种方式来升级。

比如使用rpm或者dpkg方式来安装新的包。注意config, data, logs, plugins这些目录安放的位置。

还可以从官网下载并解压zip或者tarball文件。

将旧的配置和数据文件挪到新的对应目录下,主要是config和data目录。注意修改ES中集群中目录的地址,比如config/elasticsearch.yml文件中的配置path.data,等等。

4 升级插件。

运行elasticsearch-plugin脚本来安装你需要的正确版本的插件。

5 启动新的节点。

启动新节点并确认它已经被加入cluster中。

GET _cat/nodes

6 重新配置shard allocation。

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

7 等待node恢复。

这是集群会等待shard allocation操作。node恢复后才可以开始升级下一个节点。检查方法:

GET _cat/health

查看status由黄色变为绿色。

注意:

rolling upgrade过程中,高版本节点上的primary shards不会向低版本节点上分配replicas。因为就版本可能认不出新版本的数据格式。

如果集群中只有一个高版本的节点,那么就意味着不会做replica shards的分配操作。那么这时cluster的健康状态是黄色yellow。这样的话,在继续之前查看init和relo这两个column,检查应该没有处于初始化initializing或者分配relocating的shard。

一旦另外的节点被升级,那么replica将会被分配,而cluster状态将会变绿色。

如果shard没有被sync-flushed,那么将会花些时间来恢复。我们可以使用下面请求来查看每个shard的恢复状态。

GET _cat/recovery

8 当集群稳定并且节点恢复后,开始操作其他未升级的节点。

 

Full cluster restart upgrade

参考:https://www.elastic.co/guide/en/elasticsearch/reference/current/restart-upgrade.html

如果跨越大版本升级,那么必须做full cluster restart upgrade。

1 禁止shard allocation。

当关闭一个节点时,allocation process将会立即复制这个关闭节点的shards到其他节点。这有些I/O浪费,可以通过下面命令来禁止。

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

2 做synced flush操作。

如果做了synced flush操作,那么shard recovery会加速。

POST _flush/synced

synced flush操作是一种best effort操作,当有pending的indexing操作时,它会失败。但是可以多次尝试。

3 停止并升级所有节点。

停止ES集群服务。升级每个节点。每个节点的升级参考rolling upgrade中的方法。

4 升级所有插件plugin。

升级节点时,必须升级所有插件。使用elasticsearch-plugin脚本来安装正确的插件版本。

5 启动集群。

如果设置了专用的master节点(node.master=true && node.data=false),那么应该首先启动master节点。等待他们形成集群,在处理数据节点之前选中主节点。可以通过查看日志看到进度。

一旦最少的符合条件的主节点找到彼此,他们就形成了集群并选中master。这时开始可以用_cat/health和_cat/nodes查看集群中的节点加入状态。

GET _cat/health

GET _cat/nodes

6 等待黄色状态。

当每个节点都加入集群后,就开始恢复本地存储的primary shard。如果_cat/health报告状态为红色,那么表示不是所有的primary shard都被分配。

当每个节点都恢复了本地shard,状态即变为黄色,表示所有primary shard都被恢复,而不是副本shard被分配。分配操作还是被禁止状态。

7 重新开启分配操作。

在所有的节点都加入集群后才开始副本的分配allocation of replicas。这样主节点可以将副本分配到已经拥有本地shard复制的节点上。这是对于集群中的所有节点来说,可以安全的进行shard分配设置:

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

集群这时可以开始想所有数据节点进行副本shard的分配。这时就可以安全的进行indexing和searching操作。而如果你不做indexing和searching,那么恢复速度会更加快。

可以通过API来查看进程:

GET _cat/health

GET _cat/recovery

_cat/health中的状态栏变绿后,所有主和副本shard都被分配完成。

  • 打赏
  • 点赞
  • 收藏
  • 分享
共有 人打赏支持
粉丝 14
博文 126
码字总数 70642
×
shawnplaying
如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
* 金额(元)
¥1 ¥5 ¥10 ¥20 其他金额
打赏人
留言
* 支付类型
微信扫码支付
打赏金额:
已支付成功
打赏金额: