全集群重启和滚动重启

edit

全集群重启和滚动重启

edit

可能会有你想要执行全集群重启或滚动重启的情况。在全集群重启的情况下，你关闭并重启集群中的所有节点，而在滚动重启的情况下，你一次只关闭一个节点，因此服务保持不中断。

超过低水位线阈值的节点将缓慢重启。在重启节点之前，请将磁盘使用量降低到低水位线以下。

全集群重启

edit

禁用分片分配。

当你关闭一个数据节点时，分配过程会等待 index.unassigned.node_left.delayed_timeout（默认情况下，一分钟），然后才开始将该节点上的分片复制到集群中的其他节点，这可能涉及大量的I/O。由于该节点很快就会重新启动，这种I/O是不必要的。你可以通过禁用副本分配来避免与时间赛跑，在关闭数据节点之前：
```
PUT _cluster/settings
{
  "persistent": {
    "cluster.routing.allocation.enable": "primaries"
  }
}
```
在重启大型集群时，您还可以考虑网关设置，以减少节点在处理通过发现时的初始压力。
停止索引并执行刷新。

执行一次flush可以加快分片恢复速度。
```
POST /_flush
```

暂时停止与活动机器学习作业和数据馈送相关的任务。（可选）

机器学习功能需要特定的订阅。

您有两种选择来处理在关闭集群时的机器学习作业和数据馈送：
- 暂时停止与您的机器学习作业和数据馈送相关的任务，并通过使用设置升级模式API来防止新作业的开启：
```
POST _ml/set_upgrade_mode?enabled=true
```
  当您禁用升级模式时，作业将使用自动保存的最后一个模型状态恢复。此选项避免了在关闭期间管理活动作业的开销，并且比显式停止数据馈送和关闭作业更快。
- 停止所有数据馈送并关闭所有作业。此选项在关闭时保存模型状态。当您在集群重启后重新打开作业时，它们使用完全相同的模型。然而，保存最新的模型状态比使用升级模式需要更长的时间，特别是如果您有很多作业或具有大模型状态的作业。
关闭所有节点。
- 如果您正在使用systemd运行Elasticsearch：
```
sudo systemctl stop elasticsearch.service
```
- 如果您正在使用 SysV init 运行 Elasticsearch：
```
sudo -i service elasticsearch stop
```
- 如果你正在以守护进程的方式运行 Elasticsearch：
```
kill $(cat pid)
```
执行任何需要的更改。
重启节点。

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

一旦足够多的主节点发现彼此，它们就会形成一个集群并选举出一个主节点。此时，您可以使用cat health和cat nodes API来监控加入集群的节点：
```
GET _cat/health

GET _cat/nodes
```
由 _cat/health 返回的 status 列显示了集群中每个节点的健康状态：red、yellow 或 green。
等待所有节点加入集群并报告状态为黄色。

当一个节点加入集群时，它会开始恢复存储在本地的任何主分片。_cat/health API最初报告status为red，表示并非所有主分片都已分配。

一旦节点恢复了其本地分片，集群的状态将切换为黄色，表示所有主分片已恢复，但并非所有副本分片都已分配。这是可以预期的，因为您尚未重新启用分配。延迟分配副本直到所有节点都处于黄色状态，允许主节点将副本分配给已经拥有本地分片副本的节点。
重新启用分配。

当所有节点都已加入集群并恢复了它们的主分片时，通过将 cluster.routing.allocation.enable 恢复为其默认值来重新启用分配：
```
PUT _cluster/settings
{
  "persistent": {
    "cluster.routing.allocation.enable": null
  }
}
```
一旦重新启用分配，集群将开始将副本分片分配给数据节点。此时可以安全地恢复索引和搜索，但如果您能等到所有主分片和副本分片都已成功分配，并且所有节点的状态为绿色，集群将更快地恢复。

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

GET _cat/recovery
```
重新启动机器学习作业。（可选）

如果您暂时中止了与机器学习作业相关的任务，请使用设置升级模式API 将其恢复到活动状态：
```
POST _ml/set_upgrade_mode?enabled=false
```
如果您在停止节点之前关闭了所有机器学习作业，请从Kibana或使用打开作业和启动数据馈送 API来打开作业并启动数据馈送。

滚动重启

edit

禁用分片分配。

当你关闭一个数据节点时，分配过程会等待 index.unassigned.node_left.delayed_timeout（默认情况下，一分钟），然后才开始将该节点上的分片复制到集群中的其他节点，这可能会涉及大量的I/O。由于该节点很快就会重新启动，这种I/O是不必要的。你可以通过禁用副本分配来避免与时间赛跑，在关闭数据节点之前：
```
PUT _cluster/settings
{
  "persistent": {
    "cluster.routing.allocation.enable": "primaries"
  }
}
```
在重启大型集群时，您还可以考虑网关设置，以减少节点在处理通过发现时的初始压力。
停止非必要的索引并执行刷新。（可选）

虽然您可以在滚动重启期间继续索引，但如果您暂时停止非必要的索引并执行刷新，分片恢复可以更快。
```
POST /_flush
```
暂时停止与活动机器学习作业和数据馈送相关的任务。（可选）

机器学习功能需要特定的订阅。

您有两种选择来处理在关闭集群时的机器学习作业和数据馈送：
- 暂时停止与您的机器学习作业和数据馈送相关的任务，并通过使用设置升级模式API来防止新作业的开启：
```
POST _ml/set_upgrade_mode?enabled=true
```
  当您禁用升级模式时，作业将使用自动保存的最后一个模型状态恢复。此选项避免了在关闭期间管理活动作业的开销，并且比显式停止数据馈送和关闭作业更快。
- 停止所有数据馈送并关闭所有作业。此选项在关闭时保存模型状态。当您在集群重启后重新打开作业时，它们使用完全相同的模型。然而，保存最新的模型状态比使用升级模式需要更长的时间，特别是如果您有很多作业或具有大型模型状态的作业。
- 如果您执行滚动重启，您也可以让您的机器学习作业继续运行。当您关闭一个机器学习节点时，其作业会自动移动到另一个节点并恢复模型状态。此选项使您的作业在关闭期间继续运行，但它会增加集群的负载。
在滚动重启的情况下关闭单个节点。
- 如果您正在使用systemd运行Elasticsearch：
```
sudo systemctl stop elasticsearch.service
```
- 如果您正在使用 SysV init 运行 Elasticsearch：
```
sudo -i service elasticsearch stop
```
- 如果你正在以守护进程的方式运行 Elasticsearch：
```
kill $(cat pid)
```
执行任何需要的更改。
重启你更改的节点。

启动节点并通过检查日志文件或提交_cat/nodes请求来确认它已加入集群：
```
GET _cat/nodes
```
重新启用分片分配。

对于数据节点，一旦节点加入了集群，移除cluster.routing.allocation.enable设置以启用分片分配并开始使用该节点：
```
PUT _cluster/settings
{
  "persistent": {
    "cluster.routing.allocation.enable": null
  }
}
```
在滚动重启的情况下重复。

当节点已恢复且集群稳定时，对每个需要更改的节点重复这些步骤。
重新启动机器学习作业。（可选）

如果您暂时中止了与机器学习作业相关的任务，请使用设置升级模式API 将其恢复到活动状态：
```
POST _ml/set_upgrade_mode?enabled=false
```
如果你在停止节点之前关闭了所有机器学习作业，请从Kibana或使用打开作业和启动数据馈送 API来打开作业并启动数据馈送。

« Add and remove nodes in your cluster Remote clusters »