Elasticsearch集群升级指引

背景

Elasticsearch集群的版本升级是一项重要的集群维护工作。本篇文章参考官方文档，将详细介绍相关细节。

第一部分版本升级指引

1.1 同步升级Elastic Stack组件

对于Elasticsearch的生态圈组件需要同步升级，具体配套版本可以参考官方提供的升级指南。

https://www.elastic.co/cn/products/upgrade_guide

1.2 索引兼容性

Elasticsearch对于老版本的索引（index）兼容性如下：

Elasticsearch 6.x兼容Elasticsearch 5.x中创建的索引，但不兼容Elasticsearch 2.x或更旧版本的索引。
Elasticsearch 5.x兼容Elasticsearch 2.x中创建的索引，但不不兼容Elasticsearch1.x或更旧版本的索引。

如果升级过程中遇到索引不兼容场景，升级后集群将无法正常启动。

1.3 版本升级路线

Elasticsearch版本升级具体路线总结如下：

序号	原版本	升级目标版本	支持的升级类型
1	`5.x`	`5.y`	滚动升级（其中 `y > x`）
2	`5.6`	`6.x`	滚动升级
3	`5.0-5.5`	`6.x`	集群重启
4	`<5.x`	`6.x`	`reindex`升级
5	`6.x`	`6.y`	滚动升级（其中 y > x）
6	`1.x`	`5.x`	`reindex`升级
7	`2.x`	`2.y`	滚动升级（其中 `y > x`）
8	`2.x`	`5.x`	集群重启
9	`5.0.0 pre GA`	`5.x`	集群重启
10	`5.x`	`5.y`	滚动升级（其中 `y > x`）

关于Elasticsearch的版本序列需要特别说明一下。Elasticsearch版本序列不是连续递增的，从2.4.x版本后直接跳跃到5.0.x。所以对于5.x版本，如果按照严格顺序递增编号，应该是3.x。之所以没有连续编号，主要是为了保持ELK（Elasticsearch 、 Logstash 、 Kibana）整体版本的统一。

其中第4种情况，小于5.x其实就是2.x和1.x。由于6.x对于更低版本的索引不兼容，所以需要对原集群的中索引实施reindex。方案分别为：

1.3.1 2.x升级到6.x

按照上面的升级路线有两种升级方案：

方案1：先由2.x升级到5.6版本（reindex升级索引版本），然后由5.6升级到6.x（滚动升级）；
方案2：创建全新的6.x集群，然后将旧集群中的索引数据远程reindex到新集群中；

1.3.2 1.x升级到6.x

同样有两个方案：

方案1：先由1.x升级到2.4.x版本（reindex升级索引版本），最后按照上面2.x升级到6.x的方案实施；
方案2：创建全新的6.x集群，然后将旧集群中的索引reindex到新集群中；

第二部分升级方法和具体步骤

集群升级路线中，针对不同的版本之间升级，一共有三种升级方案：滚动升级、集群重启、reindex。下面将分别介绍。

2.1 滚动升级

所谓滚动升级指的是集群中节点逐个将版本升级至目标（高）版本，升级期间集群保持对外服务不中断。这种升级方案都是针对同一个大版本内的升级，即x.y升级到x.z（z>y）。特别的，5.6升级到6.x也是支持使用滚动升级方式的。

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

通常滚动升级的步骤如下：

第1步禁用副本分片（shards）分配

在下宕升级节点前，需要提前禁止副本分片的分配。

节点下宕后，副本分配进程会等待index.unassigned.node_left.delayed_timeout（默认情况下为1分钟），然后再开始将该节点上的分片复制到群集中的其他节点，这会导致大量I/O。由于节点很快将重新启动，所以并不需要重新分配。

API命令如下：

PUT _cluster/settings

{

  "persistent": {

    "cluster.routing.allocation.enable": "primaries"

  }

}

第2步执行同步刷新

重启集群时如果translog过大，日志回放恢复数据耗时较长，建议手动同步刷新，减少translog。

注意：这个过程较为缓慢。

POST _flush/synced

第3步停止机器学习作业

如果集群中运行了机器学习任务，需要停止任务运行。

参考：https://www.elastic.co/guide/en/elastic-stack-overview/6.8/stopping-ml.html

第4部下宕待升级节点并安装主版本和插件

对升级节点实施下宕，开始文件系统的升级。

第5步启动节点

启动节点，并用下面的API检查节点是否加入集群。

GET _cat/nodes

第6步重启分片分配

节点加入集群后，设置启用分片分配开始使用该节点。

PUT _cluster/settings

{

  "persistent": {

    "cluster.routing.allocation.enable": null

  }

}

在升级下一个节点前，等待集群分片完成。可以通过下面的API检查集群状态：

GET _cat/health?v

等待集群的状态由red变成yellow，再到green。说明集群完成所有主分片和副分片的分配。

第7步重复升级其他节点

重复滚动升级集群其他节点。

第8步重启机器学习任务

如果集群中有机器学习任务，需要从新启动。

2.2 集群整体重启

集群整体重启指的是升级前将集群所有节点均下宕，集群停止对外服务，待所有节点完成升级后，整体启动集群，恢复对外服务。例如：5.6之前的版本升级到6.x需要重启集群实施升级。

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

集群重启升级步骤和滚动方式相似，主要步骤如下：

第1步禁用副本分片（shards）分配

下宕升级节点前需要，提前禁止副本分片的分配。（参考滚动升级）

第2步停止不必要的索引并执行同步刷新

参考滚动升级。

第3步停止机器学习作业

参考滚动升级

第4部下宕所有节点并安装主版本和插件

对集群所有节点实施下宕，开始文件系统版本升级。

第5步启动节点并等待集群状态为yellow

启动所有节点，并用下面的API检查所有节点是否加入集群。

GET _cat/nodes

第6步重启分片分配

节点加入集群后，设置启用分片分配开始使用该节点。

PUT _cluster/settings

{

  "persistent": {

    "cluster.routing.allocation.enable": null

  }

}

在升级下一个节点前，等待集群分片完成。可以通过下面的API检查集群状态：

GET _cat/health?v

等待集群的状态由yellow变为green。说明集群完成所有主分片和副分片的分配。

第7步重启机器学习任务

参考滚动升级

2.3 reindex

Elasticsearch中相邻版本的index具有兼容性，但是跨度较大的版本不再向下兼容。在上文（1.2 索引兼容性）中已做介绍。而在ElasticSearch中，索引的field设置是不能被修改的，如果要修改一个field，那么应该重新按照新的mapping，建立一个index，然后将数据批量查询出来，重新用bulk api写入新index中。

批量查询的时候，建议采用scroll api，并且采用多线程并发的方式来reindex数据，每次scroll就查询指定日期的一段数据，交给一个线程即可。

第1步搭建新版本集群

申请服务器资源，搭建全新版本的ElasticSearch集群。将对外服务全部指向新集群。

第2步将老集群中数据reindex到新集群

在老集群上使用reindex API将老集群中index历史数据逐步迁移至新集群。

如果集群数据量较大，迁移过程是一个很缓慢的过程。

API案例（下面是简单的配置）：

POST _reindex

{

  "source": {

    "remote": {

      "host": "http://otherhost:9200",

      "username": "user",

      "password": "pass"

    },

    "index": "source",

    "query": {

      "match": {

        "test": "data"

      }

    }

  },

  "dest": {

    "index": "dest"

  }

}

//host为远程集群（新集群）的地址。

//username和password针对安全集群的密钥验证。

//"index": "source"为旧集群中index名，dest的所对应的是新集群目标index名。

迁移完成后，可以对旧集群中数据实施清理。清理完成后根据情况需要，旧节点可以离线升级文件系统，最后作为全新的节点加入新集群。

如果旧集群中历史数据不重要，可以删除数据后，搭建全新的集群。

2.4 分步升级

对于跨度较大的版本升级，如果不采用新建集群再实施reindex方式，那么就需要分步升级。例如A、B、C依次为三个版本，版本级别A<B<C，其中index数据B兼容A，C兼容B，但是C不兼容A。这种情况需要分步升级：

A升级到B，使用滚动升级或者集群整体重启方式。
对于B版本的集群，将A版本的所有数据reindex到B版本。这个过程较为耗时。
等到集群中所有历史index（新建的index自然是B版本）均为B版本后，升级集群版本到C版本。

如果index数据是时间序列类的数据，可以不实施reindex，等到历史数据生命周期结束后（集群中不在有A版本的index数据），再从B版本升级到C版本。

总结

（1）一般Elasticsearch大版本之间跨度升级需要重启整体集群。

（2）部分ElasticSearch大版本间index并不兼容，需要对数据重索引（reindex）。

（3）大版本中的小版本升级，通常只需要滚动重启方式即可。

参考材料

1、Elasticsearch官网链接：https://www.elastic.co/cn/

更多关注：