原英文版地址: https://www.elastic.co/guide/en/elasticsearch/reference/7.7/restart-cluster.html, 原文档版权归 www.elastic.co 所有
本地英文版地址: ../en/restart-cluster.html

全集群重启和滚动重启 (Full-cluster restart and rolling restart)

你可能 希望在某些情况下执行全集群重启 或滚动重启。 在 全集群重启 的情况下,要关闭并重启集群中的所有节点,而在 滚动重启 的情况下,一次仅关闭一个节点,因此服务不会中断。

全集群重启 (Full-cluster restart)

  1. 禁用分片分配

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

    PUT _cluster/settings
    {
      "persistent": {
        "cluster.routing.allocation.enable": "primaries"
      }
    }
  2. 停止索引并执行同步刷新(flush)

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

    POST _flush/synced

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

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

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

    机器学习功能需要白金级或更高级别的许可证。 有关 Elastic 许可级别的更多信息,请参考 订阅页面

    当关闭集群时,你有两种选择来处理机器学习作业 和 数据馈送(datafeed):

    • 使用 设置升级模式(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. 重启节点。

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

    一旦有足够多的符合主节点条件的节点发现了彼此,它们就形成一个集群并选举一个主节点。 此时,您可以使用 cat healthcat nodes API 来监控加入集群的节点:

    GET _cat/health
    
    GET _cat/nodes

    status column returned by _cat/health 返回的 status 列显示了集群中每个节点的运行状况:redyellow,或 green

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

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

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

  8. 重新启用分配

    当所有节点都加入集群并恢复其主分片时,通过将 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
  9. 重新启动机器学习作业 (可选)

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

    POST _ml/set_upgrade_mode?enabled=false

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

滚动重启 (Rolling restart)

  1. 禁用分片分配

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

    PUT _cluster/settings
    {
      "persistent": {
        "cluster.routing.allocation.enable": "primaries"
      }
    }
  2. 停止索引并执行同步刷新(flush)

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

    POST _flush/synced

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

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

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

    机器学习功能需要白金级或更高级别的许可证。 有关 Elastic 许可级别的更多信息,请参考 订阅页面

    当关闭集群时,你有两种选择来处理机器学习作业 和 数据馈送 (datafeed):

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

      POST _ml/set_upgrade_mode?enabled=true

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

    • 停止所有数据馈送并关闭所有作业。 此选项保存关闭时的模型状态。 当你在集群重新启动后重新打开作业时,它们使用完全相同的模型。 但是,保存最新的模型状态比使用升级模式花费的时间更长,尤其是当你有许多作业或作业具有较大的模型状态时。
    • 如果执行滚动重启,你也可以让机器学习作业继续运行。 当你关闭机器学习节点时,它的作业会自动移动到另一个节点,并恢复模型状态。 此选项使作业能够在关闭期间继续运行,但这会增加集群的负载。
  4. 在滚动重启的情况下关闭单个节点。

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

      sudo systemctl stop elasticsearch.service
    • 如果你是使用 SysV init 运行的 Elasticsearch:

      sudo -i service elasticsearch stop
    • 如果你是以守护进程方式运行的 Elasticsearch:

      kill $(cat pid)
  5. 执行任何必要的更改。
  6. 重启你修改过的节点。

    启动节点,并通过检查日志文件或提交一个 _cat/nodes 请求来确认它已加入集群:

    GET _cat/nodes
  7. 重新启用分配。

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

    PUT _cluster/settings
    {
      "persistent": {
        "cluster.routing.allocation.enable": null
      }
    }
  8. 在滚动重启的情况下重复上述步骤。

    当节点恢复并且集群稳定后,对每个需要更改的节点重复这些步骤。

  9. 重新启动机器学习作业 (可选)

    如果你暂时停止了与机器学习作业相关联的任务,请使用 设置升级模式(set upgrade mode) API 将它们恢复到活动状态:

    POST _ml/set_upgrade_mode?enabled=false

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