升级 Elasticsearch
编辑升级 Elasticsearch
编辑Elasticsearch 集群可以一次升级一个节点,因此升级不会中断服务。不支持在同一集群中运行多个 Elasticsearch 版本超出升级的持续时间,因为分片无法从升级的节点复制到运行较旧版本的节点。
- 首先升级数据节点,逐层升级,从冻结层开始,然后是冷层,然后是温层,然后是热层,最后是任何不在层中的其他数据节点。在移动到下一层之前,完成每个数据层中所有节点的升级。这确保了 ILM 可以在升级期间继续在各层之间移动数据。您可以使用
GET /_nodes
请求获取特定层中的节点列表,例如:GET /_nodes/data_frozen:true/_none
。 - 升级所有既不是主节点候选也不是数据节点的剩余节点。这包括专用的 ML 节点、专用的摄取节点和专用的协调节点。
- 最后升级主节点候选节点。您可以使用
GET /_nodes/master:true/_none
检索这些节点的列表。
此顺序确保所有节点都可以在升级期间加入集群。升级的节点可以加入具有旧主节点的集群,但旧节点不一定可以加入具有升级主节点的集群。
要升级集群
-
禁用分片分配.
当您关闭数据节点时,分配过程会等待
index.unassigned.node_left.delayed_timeout
(默认情况下为一分钟),然后才开始将该节点上的分片复制到集群中的其他节点,这可能会涉及大量的 I/O。由于该节点很快将被重启,因此这种 I/O 是不必要的。您可以通过在关闭数据节点之前禁用副本的分配来避免与时钟赛跑PUT _cluster/settings { "persistent": { "cluster.routing.allocation.enable": "primaries" } }
-
停止非必要的索引操作并执行刷新。(可选)
虽然您可以在升级期间继续索引,但如果您暂时停止非必要的索引并执行刷新,则分片恢复会快得多。
POST /_flush
-
暂时停止与活动的机器学习作业和数据源关联的任务。(可选)
可以在升级期间让机器学习作业运行,但这会增加集群的负载。当您关闭机器学习节点时,其作业会自动移动到另一个节点并恢复模型状态。
在 7.x 之前创建的任何机器学习索引都必须在升级之前重新索引,您可以从 7.17 中的 升级助手启动此操作。
-
使用 设置升级模式 API 暂时停止与机器学习作业和数据源关联的任务,并防止打开新作业
POST _ml/set_upgrade_mode?enabled=true
当您禁用升级模式时,作业将使用自动保存的最后一个模型状态恢复。此选项避免了在升级期间管理活动作业的开销,并且比显式停止数据源和关闭作业更快。
- 停止所有数据源并关闭所有作业。此选项会在关闭时保存模型状态。升级后重新打开作业时,它们将使用完全相同的模型。但是,保存最新的模型状态比使用升级模式花费的时间更长,特别是当您有大量作业或具有大型模型状态的作业时。
-
-
关闭单个节点取决于当前用于运行 Elasticsearch 的方式。例如,如果使用
systemd
或 SysVinit
,请运行以下命令。-
如果您使用
systemd
运行 Elasticsearchsudo systemctl stop elasticsearch.service
-
如果您使用 SysV
init
运行 Elasticsearchsudo -i service elasticsearch stop
-
-
升级您关闭的节点。
- 使用
rpm
或dpkg
安装新包。所有文件都安装在操作系统和 Elasticsearch 配置文件的适当位置,不会被覆盖。
要使用 zip 或压缩 tarball 进行升级
- 将 zip 或 tarball 提取到新目录。如果您不使用外部
config
和data
目录,这一点至关重要。 - 设置
ES_PATH_CONF
环境变量,以指定外部config
目录和jvm.options
文件的位置。如果您不使用外部config
目录,请将旧配置复制到新安装中。 -
在
config/elasticsearch.yml
中设置path.data
以指向您的外部数据目录。如果您不使用外部data
目录,请将旧数据目录复制到新安装中。如果您使用监控功能,请在升级 Elasticsearch 时重复使用数据目录。监控通过使用存储在数据目录中的持久 UUID 来识别唯一的 Elasticsearch 节点。
- 在
config/elasticsearch.yml
中设置path.logs
以指向您要存储日志的位置。如果您未指定此设置,则日志将存储在您将存档提取到的目录中。
当您提取 zip 或 tarball 包时,
elasticsearch-{bare_version}
目录包含 Elasticsearch 的config
、data
和logs
目录。我们建议将这些目录移出 Elasticsearch 目录,这样在升级 Elasticsearch 时就不会删除它们。要指定新位置,请使用
ES_PATH_CONF
环境变量和path.data
和path.logs
设置。有关更多信息,请参阅重要的 Elasticsearch 配置。Debian 和 RPM 包将这些目录放在每个操作系统的适当位置。在生产环境中,我们建议使用 deb 或 rpm 包。
在执行滚动升级时,请保持
cluster.initial_master_nodes
未设置。每个升级的节点都加入现有集群,因此无需集群引导。您必须在每个节点上配置discovery.seed_hosts
或discovery.seed_providers
。 - 使用
-
升级任何插件。
使用
elasticsearch-plugin
脚本安装每个已安装的 Elasticsearch 插件的升级版本。当您升级节点时,必须升级所有插件。 -
启动升级后的节点。
启动新升级的节点,并通过检查日志文件或提交
_cat/nodes
请求来确认它是否加入了集群GET _cat/nodes
-
重新启用分片分配。
对于数据节点,一旦节点加入集群,请删除
cluster.routing.allocation.enable
设置以启用分片分配并开始使用该节点PUT _cluster/settings { "persistent": { "cluster.routing.allocation.enable": null } }
-
等待节点恢复。
在升级下一个节点之前,请等待集群完成分片分配。您可以通过提交
_cat/health
请求来检查进度GET _cat/health?v=true
等待
status
列切换为green
。一旦节点为green
,则已分配所有主分片和副本分片。在滚动升级期间,分配给运行新版本的节点的主分片不能将其副本分配给运行旧版本的节点。新版本可能具有旧版本无法理解的不同数据格式。
如果不可能将副本分片分配给另一个节点(集群中只有一个升级的节点),则副本分片将保持未分配状态,并且状态保持为
yellow
。在这种情况下,一旦没有正在初始化或正在重新定位的分片(检查
init
和relo
列),您就可以继续。一旦另一个节点升级,就可以分配副本,并且状态将更改为
green
。未刷新的分片可能需要更长的时间才能恢复。您可以通过提交
_cat/recovery
请求来监视各个分片的恢复状态GET _cat/recovery
如果您已停止索引,则在恢复完成后即可安全地恢复索引。
-
重复.
当节点恢复并且集群稳定时,对每个需要更新的节点重复这些步骤。您可以使用
_cat/health
请求来监视集群的运行状况GET /_cat/health?v=true
并使用
_cat/nodes
请求检查哪些节点已升级GET /_cat/nodes?h=ip,name,version&v=true
-
重新启动机器学习作业。
如果您暂时停止了与机器学习作业关联的任务,请使用设置升级模式 API 将它们恢复为活动状态
POST _ml/set_upgrade_mode?enabled=false
如果您在升级之前关闭了所有机器学习作业,请从 Kibana 或使用 打开作业和 启动数据源 API 打开作业并启动数据源。
滚动升级
编辑在滚动升级期间,集群继续正常运行。但是,在升级集群中的所有节点之前,任何新功能都将被禁用或以向后兼容模式运行。新功能将在升级完成后且所有节点都运行新版本后开始运行。一旦发生这种情况,就没有办法返回以向后兼容模式运行。不允许运行先前版本的节点加入完全更新的集群。
在不太可能发生的情况下,升级过程中发生网络故障,导致所有剩余的旧节点与集群隔离,您必须使旧节点脱机并升级它们,才能使其加入集群。
如果您在升级期间一次停止一半或更多的主节点候选节点,则集群将变得不可用。您必须升级并重新启动所有停止的主节点候选节点,以使集群重新形成。可能还需要升级所有其他运行旧版本的节点,以使它们能够加入重新形成的集群。
同样,如果您使用单个主节点运行测试/开发环境,则应最后升级它。重新启动单个主节点会强制集群重新形成。新集群最初将仅具有升级后的主节点,因此当旧节点重新加入集群时,新集群将拒绝旧节点。已经升级的节点将成功重新加入升级后的主节点。
已存档的设置
编辑如果升级使用目标版本中未使用的已弃用集群或索引设置的 Elasticsearch 集群,这些设置将被存档。我们建议您在升级后删除任何已存档的设置。有关更多信息,请参阅已存档设置。