数据节点下线

参考文档

集群版本

• ES: 7.3
• Kibana: 7.3

两种情况

• 数据节点和非数据节点

非数据节点

• master-eligible 节点下线须确保集群中剩余的master-eligible节点仍不低于minimum_master_nodes数量
• 否则则会造成集群无法选举 Master节点，集群崩溃
• 也可以提前修改minimum_master_nodes数量，确保集群正常

PUT /_cluster/settings
{
  "persistent": {
    "discovery.zen.minimum_master_nodes":1
  }
}

• 其他像 Coordinating Node、 Ingest Node因不包含数据又不参与集群选举，因此直接下线即可

数据节点

• 很明显，需要先将 Data Node上的分片转移到其他节点上，Data Node才能下线
• 根据 Cluster 级别的 Allocation 设置可以排查某个 Node
• 7.3 版本支持 _name、 _ip、 _host 三种属性来分配分片
• 比如我们需要将节点 Hot51 下线，则参考下述命令

PUT _cluster/settings
{
  "transient": {
    "cluster.routing.allocation.exclude._name": "Hot51"
  }
}

检查验证

• 等待分片转移完成，可以通过 Kibana 的 Monitor 来查看正在进行的 Task
• 也可以通过 Dev Tool 来查看

GET _cluster/health
{
  "cluster_name" : "XXXXXX",
  "status" : "green",
  "timed_out" : false,
  "number_of_nodes" : 79,
  "number_of_data_nodes" : 72,
  "active_primary_shards" : 14880,
  "active_shards" : 14906,
  "relocating_shards" : 10,
  "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
}

• relocating_shards 就是正在重分配的分片数量
• 等待relocating_shards数量为0`就全部迁移完成
• 同时通过确认该节点上是否还有doc来确保迁移是否完成而不是因其他因素被中断

GET _nodes/Hot51/stats/indices?human
     ....
      "indices" : {
        "docs" : {
          "count" : 1627525401,
          "deleted" : 150809024
        },
        "store" : {
          "size" : "1.1tb",
          "size_in_bytes" : 1216926382209
        },
      ....

• 等待docs.count 为 0 即该节点无任何数据了。
• 然后下线该节点即可
• 最后别忘了移除集群中的配置

PUT _cluster/settings
{
  "transient": {
    "cluster.routing.allocation.exclude._name": null
  }
}