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.x1.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/

更多关注:

posted @ 2021-04-08 20:15  翔子书记  阅读(182)  评论(0编辑  收藏