文章目录
集群概览
主机名 | 系统 | 版本 |
---|---|---|
es01 | CentOS_7.6-aaarch64 | ElasticSearch-7.17.10 |
es02 | CentOS_7.6-aaarch64 | ElasticSearch-7.17.10 |
es03 | CentOS_7.6-aaarch64 | ElasticSearch-7.17.10 |
需求
- 将三台ES节点从ElasticSearch-7.17.10升级至ElasticSearch-7.17.24; 2. 保证索引数据的正常过度,滚动升级不中断业务。
准备工作
下载新版本
下载对应的升级版本,我们选择LINUX ARM架构版本:
https://www.elastic.co/downloads/past-releases/elasticsearch-7-17-24
备份数据
略
升级实施
确认节点升级顺序
shell
curl http://localhost:9200/_cat/nodes?pretty
其中标有*
号的是主节点,标有-
的是从节点。
升级顺序按照:从->主
来进行,先下线第一个节点,完成第一个节点升级后,再进行第二个节点,最后升级主节点。
禁用副本分配
执行代码如下:
shell
curl -X PUT "localhost:9200/_cluster/settings?pretty" -H 'Content-Type: application/json' -d '{
"persistent": {
"cluster.routing.allocation.enable": "primaries"
}
}'
命令用于修改 Elasticsearch 集群的路由分配设置,在执行升级操作之前,需要暂时限制分片的重新分配,以保证集群的稳定性。
为什么在升级 Elasticsearch 集群之前要执行这个命令?
在升级 Elasticsearch 集群之前执行这个命令的原因,主要是为了 **保证数据和分片的稳定性**,防止在节点重新启动或重启过程中发生不必要的分片重新分配,避免集群在升级过程中的压力。具体有以下几点考虑:
- 防止副本分片的重分配: 当一个节点下线或重启时,Elasticsearch 可能会自动将副本分片重新分配到其他节点上,来保持数据的可用性。这样会增加集群的负载。如果集群在升级过程中节点频繁重启,这种行为可能导致大量的分片重分配操作,造成系统负载升高或资源耗尽。
- 确保主分片正常分配 : 将分片分配限制为
primaries
意味着只允许主分片的分配。升级期间,如果一个节点下线,其他节点上的主分片依然可以继续提供服务,集群能维持最基本的操作。而副本分片的分配在升级完成后再恢复,可以减轻集群的压力。 - 降低网络流量和磁盘 I/O 压力: 在升级过程中,分片的重新分配会占用大量的网络带宽和磁盘 I/O。如果不限制副本分片的重新分配,集群可能会出现性能瓶颈甚至不稳定情况。
停止ES节点
将这台节点停止,找到pid然后kill:
shell
ps -ef | grep elasticsearch
解压新版安装包
将安装包哦上传到对应目录,并解压,要提前在三台服务器上都分发执行。
shell
tar -zxvf elasticsearch-7.17.24-linux-aarch64.tar.gz
复制config文件
将旧版本的config文件复制到新版本es中。
shell
cp -r /data/elasticsearch-7.17.10/config/ /data/elasticsearch-7.17.24/
启动新版本
首先在一台节点上启动,启动之前记得把es用户组群权限赋给新版es。
shell
cd /data/elasticsearch-7.17.24/bing
su es
./elasticsearch -d -p pid
恢复集群分片分配
shell
curl -X PUT "localhost:9200/_cluster/settings?pretty" -H 'Content-Type: application/json' -d '{
"persistent": {
"cluster.routing.allocation.enable": null
}
}'
设置 cluster.routing.allocation.enable
为 null
会移除之前的持久化设置("primaries"
),让集群回到正常状态。如果不清理这个设置,集群将一直只分配主分片,副本分片不会被分配,导致数据冗余性缺失。
升级完成后执行此命令是为了让 Elasticsearch 集群恢复默认的分片分配行为,确保主分片和副本分片都能正常分配,恢复集群的高可用性和数据冗余性。这一操作是必不可少的,否则副本分片将持续处于未分配状态,集群的健壮性会受到影响。
滚动升级剩余节点
在第一台节点成功启动加入集群后,即可开始第二台节点的升级。
检查
升级流程中的检查步骤
-
升级前:
- 在升级前,使用
curl -X GET "localhost:9200/_cat/health?v=true&pretty"
来确认集群处于green
状态,确保所有分片和节点都在正常运行。 - 使用
curl -X GET "localhost:9200/_cat/nodes?h=ip,name,version&v=true&pretty"
确认当前的节点信息和版本(应该是 7.17.10)。
- 在升级前,使用
-
升级中:
- 升级过程中,每次重启节点之后,使用
curl -X GET "localhost:9200/_cat/health?v=true&pretty"
来检查集群的健康状态。如果出现yellow
状态,是由于副本分片未分配,可以继续等待直到状态恢复为green
。 - 使用
curl -X GET "localhost:9200/_cat/recovery?pretty"
监控分片的恢复进度,尤其是在重启节点之后,查看数据恢复是否顺利进行。
- 升级过程中,每次重启节点之后,使用
-
升级后:
- 升级完所有节点后,使用
curl -X GET "localhost:9200/_cat/nodes?h=ip,name,version&v=true&pretty"
确认所有节点都已经成功升级到 7.17.24,并且所有节点重新加入了集群。 - 最后,通过
curl -X GET "localhost:9200/_cat/health?v=true&pretty"
再次确认集群处于green
状态,所有主分片和副本分片都已经分配。
- 升级完所有节点后,使用