ElasticSearch-7.17.10集群升级至ElasticSearch-7.17.24

news2024/10/24 17:15:12

文章目录

集群概览

主机名	系统	版本
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 状态，所有主分片和副本分片都已经分配。