文章目录
集群概览
| 主机名 | 系统 | 版本 |
|---|---|---|
| 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 |
需求
1. 将三台ES节点从ElasticSearch-7.17.10升级至ElasticSearch-7.17.24； 2. 保证索引数据的正常过度，滚动升级不中断业务。准备工作
下载新版本
下载对应的升级版本，我们选择LINUX ARM架构版本：https://www.elastic.co/downloads/past-releases/elasticsearch-7-17-24
备份数据
略升级实施
确认节点升级顺序
curl http://localhost:9200/_cat/nodes?pretty
其中标有*号的是主节点，标有-的是从节点。
升级顺序按照：从->主来进行，先下线第一个节点，完成第一个节点升级后，再进行第二个节点，最后升级主节点。
禁用副本分配
执行代码如下：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：ps -ef | grep elasticsearch
解压新版安装包
将安装包哦上传到对应目录，并解压，要提前在三台服务器上都分发执行。tar -zxvf elasticsearch-7.17.24-linux-aarch64.tar.gz
复制config文件
将旧版本的config文件复制到新版本es中。cp -r /data/elasticsearch-7.17.10/config/ /data/elasticsearch-7.17.24/
启动新版本
首先在一台节点上启动，启动之前记得把es用户组群权限赋给新版es。cd /data/elasticsearch-7.17.24/bing
su es
./elasticsearch -d -p pid
恢复集群分片分配
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状态，所有主分片和副本分片都已经分配。
- 升级完所有节点后，使用
