Rolling upgrades

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

    支持滚动升级：

    • 在次要版本之间
    • 从5.6到6.8
    • 从6.8到7.3.0

    从6.7或更早版本直接升级到7.3.0需要重新启动完整集群。

    要执行从6.8到7.3.0的滚动升级：

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

    1. PUT _cluster/settings
    2. {
    3.   "persistent": {
    4.     "cluster.routing.allocation.enable": "primaries"
    5.   }
    6. }

    2、停止非必要索引并执行同步刷新。（可选的）
    虽然您可以在升级期间继续编制索引，但如果暂时停止非必要索引并执行同步刷新，则碎片恢复会快得多。

    1. POST _flush/synced

    3、暂时停止与活动机器学习作业和数据馈送相关的任务。（可选的）
    如果您的机器学习索引是在6.x之前创建的，则必须重新索引索引。
    如果您的机器学习索引是在6.x中创建的，您可以：

    • 在升级期间保持机器学习作业运行。关闭机器学习节点时，其作业会自动移动到另一个节点并恢复模型状态。此选项使您的作业在升级期间继续运行，但会增加群集的负载。
    • 暂时停止与计算机学习作业和数据馈送相关的任务，并使用设置的升级模式API阻止打开新作业：
      1. POST _ml/set_upgrade_mode?enabled=true
      禁用升级模式时，作业将使用自动保存的最后一个模型状态恢复。此选项可避免在升级期间管理活动作业的开销，并且比明确停止数据馈送和关闭作业更快。
    • 停止所有数据馈送并关闭所有作业。此选项在关闭时保存模型状态。在升级后重新打开作业时，它们使用完全相同的模型。但是，保存最新模型状态比使用升级模式需要更长时间，尤其是当您有大量工作或具有大型模型状态的作业时。

    4、关闭单个节点。

    • 如果您使用systemd运行Elasticsearch：
      1. sudo systemctl stop elasticsearch.service
    • If you are running Elasticsearch with SysV init:
      1. sudo -i service elasticsearch stop
    • 如果您将Elasticsearch作为守护程序运行：
      1. kill $(cat pid)

    5、升级您关闭的节点。

    要使用Debian或RPM软件包升级：

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

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

    • 将zip或tarball解压缩到新目录。如果您不使用外部配置和数据目录，这一点至关重要。
    • 设置ES_PATH_CONF环境变量以指定外部配置目录和jvm.options文件的位置。如果未使用外部配置目录，请将旧配置复制到新安装。
    • 在config / elasticsearch.yml中设置path.data以指向外部数据目录。如果未使用外部数据目录，请将旧数据目录复制到新安装。

      IMPORTANT 如果使用监视功能，请在升级Elasticsearch时重新使用数据目录。Monitoring通过使用存储在数据目录中的持久性UUID来标识唯一的Elasticsearch节点

    • 在config / elasticsearch.yml中设置path.logs以指向要存储日志的位置。如果未指定此设置，则日志将存储在您将存档解压缩到的目录中。

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

    7、安全配置
    如果使用Elasticsearch安全功能来定义域，请验证您的域设置是否是最新的。领域设置的格式在7.0版中已更改，特别是领域类型的位置已更改。请参阅领域设置。

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

    1. GET _cat/nodes

    9、启用分片分配
    节点加入群集后，删除cluster.routing.allocation.enable设置以启用分片分配并开始使用节点：

    1. PUT _cluster/settings
    2. {
    3.   "persistent": {
    4.     "cluster.routing.allocation.enable": null
    5.   }
    6. }

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

    1. GET _cat/health?v

    等待状态列从黄色切换为绿色。节点为绿色后，将分配所有主分片和副本分片。
    未同步刷新的碎片可能需要更长时间才能恢复。您可以通过提交_cat / recovery请求来监视各个分片的恢复状态：

    1. GET _cat/recovery

    如果您停止索引，则可以在恢复完成后立即恢复索引。

    11、重复
    当节点已恢复且群集稳定后，请对需要更新的每个节点重复这些步骤。

    12、重启机器学习工作
    如果您暂时停止与计算机学习作业关联的任务，请使用set upgrade mode API将它们恢复为活动状态：

    1. POST _ml/set_upgrade_mode?enabled=false

    如果在升级之前关闭了所有计算机学习作业，请打开作业并从Kibana或打开的作业启动数据馈送并启动数据源API。

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

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

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