滚动升级elasticsearch

最新推荐文章于 2022-08-15 09:18:05 发布

要加油呀

最新推荐文章于 2022-08-15 09:18:05 发布

阅读量945

点赞数

分类专栏： elk 文章标签： elasticsearch 大数据搜索引擎

本文链接：https://blog.csdn.net/weixin_45112997/article/details/126099478

版权

elk 专栏收录该内容

9 篇文章 0 订阅

订阅专栏

官网地址：

https://www.elastic.co/guide/en/elasticsearch/reference/7.17/rolling-upgrades.html#_upgrading_your_cluster

滚动升级

滚动升级允许 Elasticsearch 集群一次升级一个节点，因此升级不会中断服务。不支持在升级持续时间之后在同一集群中运行多个版本的 Elasticsearch，因为无法将分片从升级的节点复制到运行旧版本的节点。

我们强烈建议您在升级时将集群的节点分成以下两组，并按以下顺序升级：

不具备master 资格的节点。GET /_nodes/_all,master:false您可以使用或通过查找使用配置的所有节点来检索这些节点的列表node.master: false。
Master-eligible 节点，即剩余节点。您可以使用检索这些节点的列表GET /_nodes/master:true。
您可以按任何顺序升级每个组中的节点。

按此顺序升级节点可确保不符合主节点条件的节点始终运行至少与符合主节点条件的节点一样新的版本。较新的节点始终可以加入具有较旧主节点的集群，但较旧的节点不能始终加入具有较新主节点的集群。通过最后升级 master-eligible 节点，您可以确保所有 master-eligible 节点都能够加入集群，无论 master-eligible 节点是否已升级。如果您在不符合主节点的节点之前升级任何符合主节点的节点，则存在旧节点将离开集群并且在升级之前无法重新加入的风险。

支持滚动升级：

同一主要版本的次要版本之间
从 5.6 到 6.8
从 6.8 到 7.17.5
从 7.17.0 到 7.17.5 的任何版本
从 6.7 或更早版本直接升级到 7.17.5 需要完全重启集群。

准备升级

在开始升级之前仔细准备很重要。开始将集群升级到版本 7.17.5 后，您必须完成升级。一旦集群包含版本 7.17.5 的节点，它可能会对其内部状态进行无法恢复的更改。如果无法完成升级，则应丢弃部分升级的集群，部署升级前版本的空集群，并从快照中恢复其内容。

在开始将集群升级到版本 7.17.5 之前，您应该执行以下操作。

检查弃用日志以查看您是否正在使用任何弃用的功能并相应地更新您的代码。
查看重大更改并对版本 7.17.5 的代码和配置进行任何必要的更改。
如果您使用任何插件，请确保每个插件都有一个与 Elasticsearch 版本 7.17.5 兼容的版本。
在升级生产集群之前，在隔离环境中测试升级。
通过拍摄快照备份您的数据！

升级集群

1、禁用分片分配.

当您关闭一个数据节点时，分配过程会等待 index.unassigned.node_left.delayed_timeout（默认为一分钟），然后才开始将该节点上的分片复制到集群中的其他节点，这可能涉及大量 I/O。由于节点很快将重新启动，因此此 I/O 是不必要的。您可以通过在关闭数据节点之前禁用副本分配来避免争分夺秒：

PUT _cluster/settings
{
  "persistent": {
    "cluster.routing.allocation.enable": "primaries"
  }
}

curl -X PUT "localhost:9200/_cluster/settings?pretty" -H 'Content-Type: application/json' -d'
{
  "persistent": {
    "cluster.routing.allocation.enable": "primaries"
  }
}
'

2、停止不必要的索引并执行同步刷新。（可选的）

虽然您可以在升级期间继续建立索引，但如果您暂时停止非必要的索引并执行synced-flush，则分片恢复会快得多。

POST _flush/synced

curl -X POST "localhost:9200/_flush/synced?pretty"

当您执行同步刷新时，请检查响应以确保没有失败。由于挂起的索引操作而失败的同步刷新操作在响应正文中列出，尽管请求本身仍返回 200 OK 状态。如果失败，请重新发出请求。

请注意，同步刷新已被弃用，并将在 8.0 中删除。刷新与 Elasticsearch 7.6 或更高版本上的同步刷新具有相同的效果。

3、暂时停止与活动机器学习作业和数据馈送相关的任务。（可选的）

如果您的机器学习索引是在 6.x 之前创建的，则必须重新索引索引。

如果您的机器学习索引是在 6.x 中创建的，您可以：在升级期间让您的机器学习作业继续运行。当您关闭机器学习节点时，其作业会自动移动到另一个节点并恢复模型状态。此选项使您的作业可以在升级期间继续运行，但会增加集群的负载。
暂时停止与您的机器学习作业和数据馈送相关的任务，并使用设置升级模式 API防止打开新作业：

POST _ml/set_upgrade_mode?enabled=true

curl -X POST "localhost:9200/_ml/set_upgrade_mode?enabled=true&pretty"

当您禁用升级模式时，作业将使用自动保存的最后一个模型状态恢复。此选项避免了在升级期间管理活动作业的开销，并且比显式停止数据馈送和关闭作业更快。
停止所有数据馈送并关闭所有作业。此选项在关闭时保存模型状态。当您在升级后重新打开作业时，它们使用完全相同的模型。但是，保存最新的模型状态比使用升级模式需要更长的时间，尤其是当您有很多作业或具有大型模型状态的作业时。

4、关闭单个节点。

If you are running Elasticsearch with systemd:

sudo systemctl stop elasticsearch.service

If you are running Elasticsearch with SysV init:

sudo -i service elasticsearch stop

If you are running Elasticsearch as a daemon:

kill $(cat pid)

5、升级您关闭的节点。

使用Debian或RPM软件包进行升级：

使用rpm或dpkg安装新软件包。所有文件都安装在操作系统的适当位置，并且 Elasticsearch 配置文件不会被覆盖。

要使用 zip 或压缩的 tarball 进行升级：

将 zip 或 tarball 解压缩到新目录。如果您不使用外部目录config和data目录，这一点至关重要。
设置ES_PATH_CONF环境变量以指定外部config目录和jvm.options文件的位置。如果您不使用外部config目录，请将旧配置复制到新安装中。
设置path.data为config/elasticsearch.yml指向您的外部数据目录。如果您不使用外部data目录，请将旧数据目录复制到新安装中。如果您使用监控功能，请在升级 Elasticsearch 时重新使用数据目录。监控通过使用存储在数据目录中的持久 UUID 来识别唯一的Elasticsearch 节点。
设置path.logs为config/elasticsearch.yml指向您要存储日志的位置。如果您未指定此设置，则日志将存储在您将存档解压缩到的目录中。当您提取 zip 或 tarball 包时，该elasticsearch-n.n.n 目录包含 Elasticsearch config、data和logs目录。我们建议将这些目录移出 Elasticsearch 目录，以便在升级 Elasticsearch 时不会删除它们。要指定新位置，请使用ES_PATH_CONF环境变量和path.dataandpath.logs设置。有关更多信息，请参阅重要的 Elasticsearch 配置。Debian和RPM软件包将这些目录放置在每个操作系统的适当位置。在生产环境中，我们建议使用 deb 或 rpm 包进行安装。您应该cluster.initial_master_nodes在执行滚动升级时保持未设置。每个升级的节点都加入了现有的集群，因此不需要集群引导。您必须配置其中一个discovery.seed_hosts或 discovery.seed_providers在每个节点上。

6、升级插件

使用elasticsearch-plugin脚本安装每个已安装的 Elasticsearch 插件的升级版本。升级节点时必须升级所有插件。

7、如果您使用 Elasticsearch 安全功能来定义领域，请确认您的领域设置是最新的。领域设置的格式在 7.0 版中发生了变化，特别是领域类型的位置发生了变化。请参阅领域设置。

8、启动升级的节点。

启动新升级的节点并通过查看日志文件或提交_cat/nodes请求来确认它是否加入了集群：

GET _cat/nodes

curl -X GET "localhost:9200/_cat/nodes?pretty"

9、重新启用分片分配

对于数据节点，一旦节点加入集群，删除 cluster.routing.allocation.enable启用分片分配的设置并开始使用节点：

PUT _cluster/settings
{
  "persistent": {
    "cluster.routing.allocation.enable": null
  }
}

curl -X PUT "localhost:9200/_cluster/settings?pretty" -H 'Content-Type: application/json' -d'
{
  "persistent": {
    "cluster.routing.allocation.enable": null
  }
}
'

10、等待节点恢复。

在升级下一个节点之前，等待集群完成分片分配。您可以通过提交_cat/health请求来检查进度：

GET _cat/health?v=true

curl -X GET "localhost:9200/_cat/health?v=true&pretty"

等待status列切换到green。一旦节点为green，所有主分片和副本分片都已分配。

在滚动升级期间，分配给运行新版本的节点的主分片不能将其副本分配给使用旧版本的节点。新版本可能具有旧版本无法理解的不同数据格式。如果无法将副本分片分配给另一个节点（集群中只有一个升级节点），则副本分片保持未分配状态，状态保持不变yellow。在这种情况下，一旦没有初始化或重新定位分片，您就可以继续（检查init和relo列）。一旦另一个节点升级，就可以分配副本并且状态将更改为green。

未同步刷新的分片可能需要更长的时间才能恢复。_cat/recovery您可以通过提交请求来监控各个分片的恢复状态：

GET _cat/recovery

curl -X GET "localhost:9200/_cat/recovery?pretty"

如果您停止了索引，则在恢复完成后立即恢复索引是安全的。

11、重复

当节点恢复并且集群稳定后，对每个需要更新的节点重复这些步骤。_cat/health您可以通过请求监控集群的运行状况：

GET /_cat/health?v=true

curl -X GET "localhost:9200/_cat/health?v=true&pretty"

并检查哪些节点已通过_cat/nodes请求升级：

GET /_cat/nodes?h=ip,name,version&v=true

curl -X GET "localhost:9200/_cat/nodes?h=ip,name,version&v=true&pretty"

12、重新启动机器学习作业。

如果您暂时停止了与机器学习作业相关的任务，请使用设置升级模式 API将它们返回到活动状态：

POST _ml/set_upgrade_mode?enabled=false

curl -X POST "localhost:9200/_ml/set_upgrade_mode?enabled=false&pretty"

在滚动升级期间，集群继续正常运行。但是，在升级集群中的所有节点之前，任何新功能都会被禁用或以向后兼容的模式运行。一旦升级完成并且所有节点都在运行新版本，新功能就会开始运行。一旦发生这种情况，就无法返回以向后兼容模式运行。运行先前版本的节点将不允许加入完全更新的集群。

如果在升级过程中出现网络故障，将所有剩余的旧节点与集群隔离开来，您必须使旧节点脱机并升级它们以使其能够加入集群。

如果您在升级过程中同时停止一半或更多符合主节点条件的节点，则集群将变得不可用，这意味着升级不再是滚动升级。如果发生这种情况，您应该升级并重新启动所有已停止的符合主节点资格的节点，以允许集群再次形成，就像执行全集群重启升级一样。可能还需要升级所有剩余的旧节点，然后它们才能在重新形成后加入集群。