Elastic Search升级方法论

2019独角兽企业重金招聘Python工程师标准>>>

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都被分配完成。

转载于:https://my.oschina.net/shawnplaying/blog/801485