装饰网站建设运营最近时事热点

之前介绍过如何移除 Data 节点，那么如果只是短暂停止一个 Data 节点进行维护，之后再次加入集群，是否也需要按照移除节点的步骤进行操作呢？我们先梳理下核心原理。

核心原理

我们先看看节点离开集群之后集群是怎样处理的。当节点离开集群时，主节点会做出以下反应：

1. 将副本分片提升为主分片，以替换离开节点上的任何主分片。
2. 分配副本分片，补充缺失的副本。
3. 在剩余节点之间均匀的重新平衡分片。

这些操作都是为了尽快达到数据高可用状态，保护集群免受数据丢失，但也会带来额外负载。

现在我们要停止一个节点进行维护，可以先想象一下整个过程：

1. 停止节点 A
2. 主节点挑选副本分片提升为主分片，替代节点 A 上的主分片
3. 主节点分配副本分片，补充缺失的副本分片
4. 每个新副本分片都通过网络进行数据恢复
5. 集群状态变为 Green
6. 节点 A 重新加入集群
7. 主节点向节点 A 迁移分片，来重新平衡

可以看到，4，7 步都是比较消耗资源的，而且主要作用是保障了维护期间的数据高可用性。

如果集群环境比较可控，比如服务器存储有 Raid，确定只是短暂维护，我们可以通过index.unassigned.node_left.delayed_timeout 参数来避免维护期内数据恢复和再平衡操作。

分片延迟分配

index.unassigned.node_left.delayed_timeout 参数设置当节点离开集群后，等待多久才开始分配副本分片，默认之是 1 分钟。该参数不会影响将其他节点的副本分片提升为主分片。

假设我们评估维护能在 1 小时内完成，我们进行如下设置：

PUT *,-.*/_settings
{"settings": {"index.unassigned.node_left.delayed_timeout": "60m"}
}

⚠️我们排除了索引系统索引，对所有非系统索引进行了设置。

此时进行节点维护，整个过程如下：

1. 停止节点 A
2. 主节点挑选副本分片提升为主分片，替代节点 A 上的主分片
3. 主节点延迟分配副本分片，集群处于 Yellow 状态
4. 延迟倒计时 1 小时
5. 1 小时内，节点 A 重新加入集群
6. 节点 A 上的分片进行数据同步/恢复，达到最新状态（维护期间可能有数据变化）
7. 集群状态变成 Green

可以看到，我们这样操作对集群影响更小。需要注意的是，如果设置了这个参数，一旦要永久移除一个节点时，也会等待 1 小时才开始分配分片。这时候我们可以调整下参数让集群立即分配分片。

PUT *,-.*/_settings
{"settings": {"index.unassigned.node_left.delayed_timeout": "0"}
}

一旦集群开始恢复数据后，就可以恢复原来的延迟设置了。