Elasticsearch 节点下线流程

情况是这样的：一些节点部署较早，跟别的服务混用，如 MongoDB、nfs等等。在服务混用的情况下，当资源不够时，就会出现竞争，竞争造成频繁的用户态和内核态之间切换，造成系统繁忙，IO异常，连累了别的服务，直接造成整个服务器上的服务不可用。

为了避免这种问题，只好将 es 节点迁走到干净的服务器上，让 es 这种 IO 大户自己一个人在服务器上玩。

所以就有了节点下线的需求。除了这种情况需要节点下线，还有别的情况也需要节点下线。更重要的是，为了保障可靠性，节点下线都要走人工控制的方式，所以特别需要写下这个节点下线流程的文章，去规范、约束和方便日后查找。

现状 es 版本为5.6.3，下面所有操作都是基于 5.6.3 版本

那么，es 节点迁走涉及三个问题：

1、节点怎样迁走才能保证集群正常
2、节点自身所维护的数据怎么迁走
3、怎么确保节点是真正迁走了

如何获取集群状态

获取集群状态这步很关键，用于确保整个节点下线过程中集群是否有异常，并且能够及时作出反应。

获取集群状态可以通过下面请求：

curl -s http://172.25.52.191:39202/_cluster/health\?pretty

返回下面信息：

{
  "cluster_name" : "bi-data-es-production",
  "status" : "green",
  "timed_out" : false,
  "number_of_nodes" : 12,
  "number_of_data_nodes" : 12,
  "active_primary_shards" : 8804,
  "active_shards" : 17608,
  "relocating_shards" : 2,
  "initializing_shards" : 0,
  "unassigned_shards" : 0,
  "delayed_unassigned_shards" : 0,
  "number_of_pending_tasks" : 0,
  "number_of_in_flight_fetch" : 0,
  "task_max_waiting_in_queue_millis" : 0,
  "active_shards_percent_as_number" : 100.0
}

找到 status，里面的值有 green、red、yellow，每个值的含义如下：

green 绿灯，所有分片都正确运行，集群非常健康。
yellow 黄灯，所有主分片都正确运行，但是有副本分片缺失。这种情况意味着 ES 当前还是正常运行的，但是有一定风险。
red 红灯，有主分片缺失。这部分数据完全不可用。而考虑到 ES 在写入端是简单的取余算法，轮到这个分片上的数据也会持续写入报错。

通过发起请求获取集群状态，就可以根据状态值判断集群的健康状态。

约定节点下线流程

1、确保相关服务不再使用下线节点的 ip
2、执行节点下线请求
3、观察集群是否开始执行下线处理的重新分配
4、等待分片分配完成
5、检查下线机器的磁盘容量，检查是否还有分片还留在机器上
6、检查通过后，停掉下线节点的 es 服务
7、修改 es 配置文件，去掉 discovery_hosts
8、禁止 es 服务开启启动
9、根据需求确定是否需要删除 es 存储数据

执行节点下线请求

操作前请确保相关服务不再使用下线节点的 ip

节点下线的操作，以 172.25.52.12 这个节点 ip 为例，在 kibana 的 console 发起下面请求

PUT _cluster/settings
{
  "transient" : {
    "cluster.routing.allocation.exclude._ip" : "172.25.52.12,172.25.52.13"
  }
}

节点下线只需要上面这条请求即可，如果有多台服务器需要下线，在后面用逗号隔开然后写入节点 IP。

注意事项：如果提交的命令有两个，它会覆盖前一个，被下线的服务器会把数据迁移后才会在集群中消失，如果数据没被迁移完，又执行了命令，这个节点不会被下线。

检查是否请求成功，在 kibana 的 console 发起下面请求

GET _cluster/settings

观察集群是否开始执行下线处理的重新分配

有两种方法：

方法一：

在终端里发起下面请求

curl -s http://172.25.52.191:39202/_cluster/health\?pretty

检查 relocating_shards 的值是否大于 0，如果大于 0 ，说明已经开始重新分配了

方法二：

在 kibana 的 console 发起下面请求

GET _cat/shards

正在 relocating shards，大概长下面的样子：

twitter 0 p RELOCATING 3014 31.1mb 192.168.56.10 H5dfFeA -> -> 192.168.56.30 bGG90G

这两个方法也能检查分片分配是否完成。

检查下线机器的磁盘容量

ssh 登陆到机器上，执行下面命令，目录为 es 的数据目录：

du -d 1 -h /exports_data/elasticsearch/lib

返回下面信息，发现容量明显比之前的 150G 少了

104M    /exports_data/elasticsearch/lib/nodes
104M    /exports_data/elasticsearch/lib

通过【观察集群是否开始执行下线处理的重新分配】的方法也可以知道集群是否分片分配完成

停掉 es 服务

sudo systemctl stop elasticsearch.service

禁止 es 开机启动

sudo systemctl disable elasticsearch.service

修改配置，去掉 discovery_hosts

cd  /etc/elasticsearch
vim elasticsearch.yml

找到discovery.zen.ping.unicast.hosts ，修改值为[]，空数组的值才能保证节点不会出现重新加入到集群的情况。

总结

至此，节点下线流程基本上已完成。整个流程比较繁琐，需要不断去确定是否正确操作。

但是，严苛流程才将出错的几率大大降低。稳住才能赢！

参考资源

分片检查：https://www.elastic.co/guide/en/elasticsearch/reference/5.6/cat-shards.html
分片迁移：https://www.elastic.co/guide/en/elasticsearch/reference/5.6/allocation-filtering.html
集群健康检查：https://www.elastic.co/guide/en/elasticsearch/reference/5.6/cluster-health.html

本文由 Chakhsu Lau 创作，采用知识共享署名4.0 国际许可协议进行许可。
本站文章除注明转载/出处外，均为本站原创或翻译，转载前请务必署名。