升级 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}
目录包含 Elasticsearchconfig
、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 集群,而这些设置在目标版本中未使用,则会将其存档。我们建议您在升级后删除任何存档设置。有关更多信息,请参阅存档设置。