干货 | Elasticsearch 8.X 版本升级指南
1、Elasticsearch 版本升级常见问题问题1:我现在集群是:5.X、6.X、7.X,要不要升级?问题2:版本跨度这么大,如何升级?7月6日,读者凌晨 00:30 留言:“怎么不出升级的文章呢?需求比较迫切,所以,就有了今天的文章。我们系统得敲一遍,让大家明白如何升级。2、Elasticsearch 要不要升级?Elasticsearch 版本迭代历史如下:Ela...
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 爱好者一起精进!
比同事抢先一步学习进阶干货!
更多推荐
所有评论(0)