原英文版地址: https://www.elastic.co/guide/en/elasticsearch/reference/7.7/restart-upgrade.html, 原文档版权归 www.elastic.co 所有
本地英文版地址: ../en/restart-upgrade.html
重要: 此版本不会发布额外的bug修复或文档更新。最新信息请参考 当前版本文档。
Elasticsearch 权威指南 [7.7] » 升级Elasticsearch » 全集群重启升级
« 滚动升级 在升级前重新索引 »

全集群重启升级 (Full cluster restart upgrade)

要从版本 6.0-6.7 直接升级到 Elasticsearch 7.7.1，必须关闭集群中的所有节点，将每个节点升级到 7.7.1，然后重新启动集群。

如果你运行的是 6.0 之前的版本，请 升级到 6.8 并重新索引旧的索引，或者启动新的7.7.1集群并 从远程重新索引。

准备升级

在开始升级之前，认真准备非常重要。 一旦开始将集群升级到版本 7.7.1，则必须完成升级。 一旦集群包含 7.7.1 版本的节点，它可能会对其内部状态进行无法撤销的更改。 如果无法完成升级，则应放弃这个已部分升级的集群，部署一个升级前的版本的空集群，并从快照恢复内容。

在开始将集群升级到 7.7.1 版之前，你应该执行以下操作：

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

升级集群

要执行到 7.7.1 的全集群重启升级，请执行以下操作:

  1. Disable shard allocation.

    当你关闭一个节点时，分配进程会等待 index.unassigned.node_left.delayed_timeout (默认值为 1 分钟)，然后开始将该节点上的分片复制到集群中的其他节点，这可能会涉及大量 I/O。 由于该节点将很快重新启动，因此不需要此 I/O。 通过在关闭节点之前 禁用副本分配，可以避免与时间赛跑： 

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

  2. 停止索引并执行 同步刷新(synced flush)。

    执行 同步刷新(synced-flush) 可以加速分片的恢复。 

    POST _flush/synced

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

    请注意，同步刷新已过时，将在8.0中删除。 Elasticsearch 7.6 或更高版本上的 刷新(flush) 与 同步刷新(synced flush) 效果相同。

  3. 暂时停止与主动机器学习工作和数据馈送(datafeed)相关的任务。 (可选)

    如果你的机器学习索引是在 6.x 之前创建的，你必须 在升级前重新索引这些索引。

    如果你的机器学习索引是在 6.x 中创建的，你可以：

    • 在升级过程中让机器学习作业继续运行。 当你关闭机器学习节点时，它的作业会自动移动到另一个节点，并恢复模型状态。 此选项使作业能够在关闭期间继续运行，但这会增加集群的负载。

    • 使用 设置升级模式(set upgrade mode) API 暂时停止与机器学习作业和数据馈送(datafeed)相关联的任务，并阻止新作业打开: 

      POST _ml/set_upgrade_mode?enabled=true

      当禁用升级模式时，作业将继续使用自动保存的最后一个模型状态。 此选项避免了升级期间管理活动作业的开销，并且比显式停止数据馈送和关闭作业更快。

    • 停止所有数据馈送(datafeed)并关闭所有作业. 此选项保存关闭时的模型状态。 升级完成后重新打开作业时，它们使用完全相同的模型。 但是，保存最新的模型状态比使用升级模式花费的时间更长，尤其是当你有许多作业或作业具有较大的模型状态时。

  4. 关闭所有节点。

    • 如果你是使用 systemd 运行的 Elasticsearch：

      sudo systemctl stop elasticsearch.service

    • 如果你是使用 SysV init 运行的 Elasticsearch：

      sudo -i service elasticsearch stop

    • 如果你是以守护进程方式运行的 Elasticsearch：

      kill $(cat pid)

  5. 升级所有节点。

    如果你是从 6.2 或更早版本升级并使用 X-Pack，请在升级前运行 bin/elasticsearch-plugin remove x-pack 以删除 X-Pack 插件。 X-Pack 功能现在包含在默认发行版中，不再单独安装。 如果 X-Pack 插件存在，节点升级后不会启动。 你需要降级，删除插件，并重新应用升级。

    要使用 Debian 或 RPM 包升级：

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

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

    1. 将 zip 或 tarball 解压缩到一个新目录。 如果不使用外部 config 和 data 目录，这一点非常重要。
    2. 设置 ES_PATH_CONF 环境变量，以指定外部 config 目录和 jvm.options 文件的位置。 如果没有使用外部 config 目录，请将旧的配置复制到新的安装目录中。

    3. 将config/elasticsearch.yml 中的 path.data 设置为你的外部 data 目录。 如果没有使用外部 data 目录，请将旧的数据目录复制到新的安装目录中。

      如果使用了监控功能，请在升级 Elasticsearch 时重复使用数据目录。 监控通过使用存储在数据目录中的持久 UUID 来识别唯一的 Elasticsearch 节点。

    4. 将 config/elasticsearch.yml 中的 path.logs 设置为存储日志的位置。 如果不指定此设置，日志将存储在归档文件解压缩到的目录中。

    当你提取 zip 或 tarball 包时， elasticsearch-n.n.n 目录包含 Elasticsearch config、data 和 logs目录。

    建议将这些目录移出 Elasticsearch 目录，这样在升级 Elasticsearch 时就没有机会删除它们。 要指定新位置，请使用 ES_PATH_CONF 环境变量以及 path.data 和 path.logs 设置。 更多信息请参考 Elasticsearch的重要的配置.

    Debian 和 RPM 包将这些目录放在每个操作系统的适当位置。 在生产环境中，我们建议使用 deb 或 rpm 包进行安装。

如果是从 6.x 集群升级，还必须通过在符合主节点条件的节点上设置 cluster.initial_master_nodes设置 来配置集群引导。

  1. 升级插件。

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

  2. 如果你使用了 Elasticsearch 安全功能来定义 领域(realm)，请验证你的领域设置是最新的。 在 7.0 版中，领域设置的格式发生了变化，尤其是领域类型的位置发生了变化。 参考领域设置。

  3. 启动每一个升级后的节点。

    如果你有专用的主节点，请先启动它们，等待它们形成集群，并在继续处理数据节点之前选举一个主节点。你可以通过查看日志来检查进度。

    一旦足够多的符合主节点条件的节点发现了彼此，它们就形成一个集群并选举一个主节点。 此时，可以使用 _cat/health 和 _cat/nodes 来监视加入集群的节点： 

    GET _cat/health

GET _cat/nodes

    _cat/health 返回的 status 列显示了集群中每个节点的健康状况：red、yellow 或 green。

  4. 等待所有节点加入集群，并报告 yellow 状态。

    当一个节点加入集群时，它开始恢复本地存储的任何主分片。 _cat/health API 最初报告 red 的 status(状态)，表示尚未分配所有主分片。

    一旦节点恢复其本地分片，集群 status 将切换为 yellow，表示所有主分片都已恢复，但并非所有副本分片都已分配。 这是意料之中的，因为尚未重新启用分配。 延迟副本的分配直到所有节点都是 yellow 的，这将允许主节点将副本分配给已经具有本地副本分片的节点。

  5. 重新启用分配。

    当所有节点都加入集群并恢复其主分片时，通过将 cluster.routing.allocation.enable 恢复为默认值来重新启用分配： 

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

    一旦重新启用分配，集群就开始向数据节点分配副本分片。 此时，恢复索引和搜索是安全的，但是如果你能够等到所有主分片和副本分片都已成功分配并且所有节点的状态都为 green，你的集群将恢复得更快。

    你可以使用 _cat/health 和 _cat/recovery API 来监控进度：

    GET _cat/health

GET _cat/recovery

  6. 重新启动机器学习作业。

    如果你暂时停止了与机器学习作业相关联的任务，请使用 set upgrade mode API 将它们恢复到活动状态： 

    POST _ml/set_upgrade_mode?enabled=false

    如果在停止节点之前关闭了所有机器学习作业，请打开作业并从 Kibana 启动数据馈送，或者使用 open jobs 和 start datafeed API。

« 滚动升级 在升级前重新索引 »