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 查看索引列表截图如下：
注：如果是多个节点，需要提前部署好 8.1.X的多个节点的集群环境。
5、小结
看似比较繁琐，梳理清楚后也就比较清晰了。
很多细节可能会和本文由细微差异或者还有本文没有覆盖到的点，建议参考官方文档。
Elasticsearch 采用了非常保守的升级策略，本质上是让集群的维护者、使用者自己去把控风险，手动升级。这或许也是 Elasticsearch 官方没有提供一键升级的原因。
因为，中间环节有太多不可控的因素。如果一键升级，每个用户的集群环境千差万别，会出各种问题。
全部交给用户手动升级，复杂是复杂了点，但这是保留用户体验方面折中的实现方案。
未来有没有可能出一键升级的方案呢？我们都很期待......
你的 Elasticsearch 集群是什么版本？有没有升级到最新版本呢？
欢迎留言交流。
推荐阅读
更短时间更快习得更多干货！
和全球 1700+ Elastic 爱好者一起精进！
比同事抢先一步学习进阶干货！
