干货 | Elasticsearch 8.X 版本升级指南

1、Elasticsearch 版本升级常见问题

问题1：我现在集群是：5.X、6.X、7.X，要不要升级？

问题2：版本跨度这么大，如何升级？

7月6日，读者凌晨 00:30 留言：“怎么不出升级的文章呢？

需求比较迫切，所以，就有了今天的文章。

我们系统得敲一遍，让大家明白如何升级。

2、Elasticsearch 要不要升级？

Elasticsearch 版本迭代历史如下：

Elasticsearch 的特点就是一个字快！

• 速度快，PB级别数据全文检索秒级响应，这是用户群体大的根因，不展开论述。
• 版本更新快，几乎每个月都更新一个小版本，大版本基本2年左右升级一次。

所以，市面上的各家公司在使用 Elasticsearch 过程中，都有自己的版本选型。根据我个人的调研和不完全观察，当前 1.X、2.X、5.X、6.X、7.X、8.X 版本都有大量的公司在使用。

面临 Elasticsearch 的如此快速的迭代，大家都会有如下的疑惑：

• 要不要升级？
• 怎么升级？
• 当前集群规模几十个甚至数百个节点，如何升级？
• 升级有没有风险？会不会导致集群不可用？
• 升级后，原有的 LowLevel REST客户端、HighLevel REST 客户端还能不能用？
• 升级有没有兼容性问题？
• 升级不成功或者成功后用得不爽，能否回退？
• 新版本听说安全成为必选项，好不好用，如何用？
• ......

层出不穷的问题，加上公司内部产品线版本的选型非一个人说了算，一般是群策群力，在充分调研或者验证的基础上，才敢给出具体的结论和可行的方案。

不升级是基于上面的疑惑，升级的原因如下：

• 8.X 高版本的安全加固已成必须，想不做安全都变得很困难。
• 8.X 高版本会在7.X版本上做的升级，低版本已知bug都已修复，理论上性能也更优。
• 8.X 的新特性、新 feature，只有升级才能使用。
• 现在不升级，未来推出 9.X 甚至 10.X，再升级可能会更麻烦。
• ......

本文不做理论层面的过多阐释，直接拿已有的 7.13 版本的单节点 Elasticsearch集群一步步升级到 8.1.3 版本。

为什么没有选择最新的 8.3+ 版本？因为 Elastic 认证的版本刚从 7.13.0 升级到 8.1.3，我们就模拟这个版本。

3、版本升级认知

3.1 确定版本升级路线

想升级到哪个版本，就先看哪个版本的官方文档。

官方文档位置：

​​https://www.elastic.co/guide/en/elastic-stack/8.1/upgrading-elastic-stack.html​​

上面的说明很关键，针对不同的版本会有不同的升级步骤。

如果是 8.1.3 之前的 8.X 版本，直接升级就可以。

如果是 7.X 版本，需要先升级至7.X 最新版：7.17.5（下图蓝色部分），然后再由 7.17.5 升级到我们期望的 8.X 版本（下图红色部分）。

3.2 在路线的基础上，敲定升级步骤

由于我们是7.13版本，所以需要先升级到 7.17.5 版本。

这时候，再看 7.17.5 版本的官方文档。

​​https://www.elastic.co/guide/en/elastic-stack/7.17/upgrading-elastic-stack.html#prepare-to-upgrade​​

根据上面的版本选择并敲定如下的滚动升级步骤。

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

当升级到 7.17.5 之后，再看如何升级到 8.1.3 版本。

需要再次打开 8.1.3 版本的官方文档，敲定出：7.17.5 升级 到 8.1.3 版本的滚动升级步骤如下：

​​https://www.elastic.co/guide/en/elastic-stack/8.1/upgrading-elastic-stack.html#prepare-to-upgrade​​

本质上，这一步就简单了，借助：reindex 方式实现。

3.3 升级风险预案

升级势必会有风险，且不可回退。

所以，建议提前做好集群的​​快照​​，以备不时之需。

这是大前提，大家一定要做好万全的准备！

4、版本升级实战

现有集群：7.13.0版本，单节点。

7.13.0 版本已有数据列表。

两步骤策略如下：

第一步：7.13.0 版本升级到 7.17.5 版本。

第二步：7.17.5 版本升级到 8.1.3 版本。

4.1 7.13.0 升级到 7.17.5 实战

如下的操作针对的是云服务器上的 7.13.0 版本的集群。

步骤1：禁用副本分片分配

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

单个节点不存在副本的分配，但是多个节点的集群环境，当一个节点关闭后，相关的分片会重新分配，并产生大量的磁盘IO。

步骤2：同步刷新

POST _flush/synced

停止非必要的索引操作并执行同步刷新，分片恢复会快得多。

步骤3：逐个kill掉节点。

pkill -f elasticsearch

我演示的是单个节点，直接暴力 kill 掉进程就可以。

步骤4：执行升级

1.  解压elasticsearch-7.17.5.tar.gz

这点和我们理想的不一样，不是点点按钮就能升级，而是底层文件层面的手动操作升级。

需要我们先下载 7.17.5 的安装包，部署细节不赘述。

2. 拷贝7.13版本的配置到7.17.5版本。

• 拷贝 config 路径
• 拷贝 jvm.options 文件（官方专门强调的）

cp -r ./elasticsearch-7.13.0/config/  ./elasticsearch-7.17.5/

上面已经全路径拷贝，下面有点多余了。

cp -r ./elasticsearch-7.13.0/config/jvm.options ./elasticsearch-7.17.5/config/jvm.options

3. 拷贝7.13版本下的path.data路径内容到7.17.5版本。

cp -r ./elasticsearch-7.13.0/data ./elasticsearch-7.17.5/

拷贝完，更新一下用户和用户组权限：

chown -R elasticsearch:elasticsearch elasticsearch-7.17.5

步骤5：更新插件、更新安全等

原集群只安装了中文分词 IK 插件，所以要先卸载该插件。

./bin/elasticsearch-plugin remove analysis-ik

再安装新版本插件

./bin/elasticsearch-plugin install https://github.com/medcl/elasticsearch-analysis-ik/releases/download/v7.17.5/elasticsearch-analysis-ik-7.17.5.zip

步骤6：启动7.17.5版本节点

到此为止，7.13.0 升级为 7.17.5 完成！

但，总体进度只完成了一半，我们的目标是：8.1.X版本。

注：如果是多个节点，需要重复上面的步骤。

革命尚未成功，同志仍需努力！

4.2 7.17.5 升级到 8.1.3 实战

步骤 1：安装好 Elasticsearch 8.1.3，Kibana 8.1.3 版本。

具体部署推荐参考：

​​云服务器 Centos7 部署 Elasticsearch 8.0 + Kibana 8.0 指南​​

​​Windows 部署 Elasticsearch + kibana 8.0 指南​​

步骤 2：执行批量 reindex。

这里明显和 7.13.0 升级到 7.17.5 不一样了，采用了 reindex 索引数据迁移方式来实现了。

跨集群的 ​​reindex​​，需要提前设置好白名单。

白名单设置位置——在目标集群的 elasticsearch.yml 文件中添加，源集群的节点ip，设置如下：

步骤3：批量脚本 reindex 迁移。

单个脚本验证ok，剩下的交个脚本。

如下是单个脚本的 reindex 迁移数据实现：

curl -XPOST   -H "Content-Type: application/json"  --cacert config/certs/http_ca.crt -u elastic:mimaxx 'https://localhost:9200/_reindex' -d '
{
  "source": {
    "remote": {
      "host": "http://172.21.0.14:19200",
      "username": "elastic",
      "password": "mima22x"
    },
    "index": "users"
  },
  "dest": {
    "index": "users"
  }
}'

全量集群索引的批量脚本 reindex 实现如下

#!/bin/sh
index_array=($(curl -XGET  -H "Content-Type: application/json"   -u elastic:mimaXXX 'http://172.21.0.14:19200/_cat/indices?v' | awk -F " " '{ print $3 }'))
echo ${index_array[@]}

for(( i=0;i<${#index_array[@]};i++)) do
echo ${index_array[i]};
cur_index_name=${index_array[i]};

curl -XPOST   -H "Content-Type: application/json"  --cacert config/certs/http_ca.crt -u elastic:mimaXXXX 'https://localhost:9200/_reindex' -d '
{
  "source": {
    "remote": {
      "host": "http://172.21.0.14:19200",
      "username": "elastic",
      "password": "mimaxxx"
    },
    "index": "'"${cur_index_name}"'"
  },
  "dest": {
    "index": "'"${cur_index_name}"'"
  }
}'

done;

核心就两个步骤：

• 步骤1：批量获取 7.17.5 版本的集群的全量索引名称。
• 步骤2：挨个遍历索引名称列表借助 reindex 实现跨集群索引迁移。

脚本执行截图：

8.1.3 版本 kibana 查看索引列表截图如下：

5、小结

看似比较繁琐，梳理清楚后也就比较清晰了。

很多细节可能会和本文由细微差异或者还有本文没有覆盖到的点，建议参考官方文档。

Elasticsearch 采用了非常保守的升级策略，本质上是让集群的维护者、使用者自己去把控风险，手动升级。这或许也是 Elasticsearch 官方没有提供一键升级的原因。

因为，中间环节有太多不可控的因素。如果一键升级，每个用户的集群环境千差万别，会出各种问题。

全部交给用户手动升级，复杂是复杂了点，但这是保留用户体验方面折中的实现方案。

未来有没有可能出一键升级的方案呢？我们都很期待......

你的 Elasticsearch 集群是什么版本？有没有升级到最新版本呢？

欢迎留言交流。

文章转载自公众号：铭毅天下Elasticsearch