升级 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 节点,该 UUID 存储在数据目录中。
- 在
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 集群使用目标版本中已弃用的集群或索引设置,则这些设置将被归档。建议您在升级后删除所有已归档的设置。有关更多信息,请参阅已归档的设置。