滚动重启 (Rolling Restart)edit

总有一天你会需要做一次集群的滚动重启 —— 保持集群在线和可操作,但是把节点逐一下线。

常见的原因:Elasticsearch 版本升级,或者服务器自身的一些维护操作(比如操作系统升级或者硬件相关)。不管哪种情况,都要有一种特别的方法来完成一次滚动重启。

从本质上讲,Elasticsearch 希望你的数据被完全的复制和均衡的分布。 如果你手动关闭了一个节点,集群会立刻发现节点的丢失并开始再平衡。 如果你知道节点维护是短期的工作,这一点就很烦人了,因为大型分片的再平衡需要花费相当的时间(想想尝试复制 1TB 的数据 —— 即便在高速网络上也是不一般的事情了)。

我们需要做的是告诉 Elasticsearch 推迟再平衡,因为我们对外部因子影响下的集群状态更了解。操作流程如下:

  1. 可能的话,停止索引新的数据并执行 同步刷新(synced flush)。虽然不是每次都能真的做到,但是这一步可以帮助提高恢复速度。 同步刷新(synced flush) 请求是“最大努力”操作。 如果存在任何挂起的索引写入操作,则会失败,但如果有必要,可以多次重新发出请求(这是安全的)。
    POST /_flush/synced
  2. 禁止分片分配。 这一步阻止 Elasticsearch 再平衡缺失的分片,直到你告诉它可以进行了。 如果你知道维护窗口会很短,这个主义就很好。 你可以像下面这样禁止分配:

    PUT /_cluster/settings
    {
        "transient" : {
            "cluster.routing.allocation.enable" : "none"
        }
    }
  3. 关闭单个节点。
  4. 执行维护/升级。
  5. 重启节点,然后确认它加入到集群了。
  6. 用如下命令重启分片分配:

    PUT /_cluster/settings
    {
        "transient" : {
            "cluster.routing.allocation.enable" : "all"
        }
    }

    分片再平衡会花一些时间。一直等到集群变成 green 状态后再继续。

  7. 对剩余节点重复第 2 到 6 步。
  8. 到这步你可以安全的恢复索引了(如果你之前停止了的话),不过等待集群完全均衡后再恢复索引,会有助于提高处理速度。