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）大版本中的小版本升级，一般只须要滚动重启方式便可。

参考材料

一、Elasticsearch官网 连接：https://www.elastic.co/cn/

更多关注：