ES集群滚动升级

发表于 | 分类于

滚动升级

滚动升级即每次升级一个集群节点，但有以下的注意事项：

  • 先升级普通的数据节点，最后升级 master ，否则老版本的 node 无法加入到新版本集群中，集群就分裂开了！
  • 支持滚动升级的版本为：mirror 版本之间，跨大版本之间只支 持 5.6--->6.8， 6.8--->7.2.1，其余情况需要 full cluster restart，或者多次升级。

升级准备

  • 检查 deprecation log，确认是否有使用涉及到已过期的功能，需要对数据进行变更处理的修改这部分内容！
  • 必要时需修改相关应用的 code 和配置！
  • 对使用了插件的，需要确认升级后的版本，也具有相应版本的插件，例如 ik！
  • 升级集群之前，现在测试环境中进行。不要直接对生产环境操作！
  • 通过 snapshot 备份好数据!

升级

1. 停止分片分配：

当一个节点下线时， allocation 的进程会等待 index.unassigned.node_left.delayed_timeout 默认一分钟 ，然后开始将该节点上的分片移动到其他节点上。这个过程会消耗较大的 I/O 资源。由于滚动升级很快就会重新启动该节点，为了避免这个过程，可以通过如下配置，停止分片的 allocation
，详细说明见 Modules[shard allocation] 模块。

  • all ,允许所有分片（主、副）的分配
  • primaries ，只允许主分片
  • new_primaries ，只允许新建索引的主分片分配
  • none ，不允许所有分片分配
1
2
3
4
5
6
7
//primaries表示只对主分片进行allocation，确保数据不丢失，副本可以不处理。
PUT _cluster/settings
{
    "persistent": {
        "cluster.routing.allocation.enable": "primaries"
    }
}

2. 停止不必要的indexing操作，启用同步flush（非必要）

对于无需更新，或者很少更新的数据会很有用

1
2
3
4
5
6
7
8
//检查是否有syncid 标记
GET index_name/_stats?filter_path=**.commit&level=shards 

//手动执行synced flush，无需等待5分钟
POST _flush/synced

//指定索引名称
POST kimchy,elasticsearch/_flush/synced

手动执行 synced flush 后会返回成功数量、失败数量

3.临时停止活动中的 ML 任务（可选）

4.停止需要升级的节点

1
2
3
4
5
6
sudo systemctl stop elasticsearch.service

sudo -i service elasticsearch stop

//最好不要用kill -9，可能会造成某些操作来不及做
kill $(cat pid)

5. 解压或安装新版本的Elasticsearch

  • 解压新版本到新的目录下，修改 jvm.options 设置
  • 设置 path.data、path.logs 指向原来的目录，或者通过 copy 覆盖当前目录
  • 无需设置 cluster.initial_master_nodes,滚动升级的节点都是加入到已经存在的集群中，所以无需设置
  • 需要在每个节点设置 discovery.seed_hosts 或 discovery.seed_providers中的一个

6. 升级插件

7. Realm Settings

8.启动节点，并确保加入到了集群中

1
GET _cat/nodes

9. 打开 shard allocation

1
2
3
4
5
6
PUT _cluster/settings
{
  "persistent": {
    "cluster.routing.allocation.enable": null
  }
}

10. 等待集群恢复

在升级下一个节点之前，先等待集群健康恢复为绿色。

1
GET _cat/health?v

  • 在滚动升级期间，运行新版本的节点的主分片无法分配副本给具有旧版本的节点。因为新版本可能具有旧版本无法理解的其他数据格式
  • 如果无法将副本分片分配给另一个节点（集群中只有一个升级的节点），则副本分片将保持未分配状态，并且状态显示为 yellow 是正常情况，升级第二个节点后就可以变为 green 了。
  • 没有使用 synced flush 的分片恢复将会更慢，通过如下请求，可以查看恢复进度

    GET _cat/recovery

11. 重复上述步骤，直到整个集群升级完成、最后，重启 ML 任务

官方文档链接

0%