所谓集群管理是指集群搭建好后的日常维护和管理。
一 集群健康
集群状态分为三种：
green : 所有主分片以及副分片都可用；
yellow：部分副本不可用；
red:丢失分片
其中集群状态为 green 和 yellow ，集群正常，数据完整；状态为red部分数据丢失，分配到缺失分片的操作会有异常；
集群状态以及分片状况可以通过kibana查看, 也可以通过下列命令查看
GET _cluster/health结果如下：
-
{ -
"cluster_name": "cluster_name_example", -
"status": "green", -
"timed_out": false, -
"number_of_nodes": 6, -
"number_of_data_nodes": 6, -
"active_primary_shards": 64, -
"active_shards": 132, -
"relocating_shards": 0, -
"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 -
}
其中cluster_name 为集群名称，status状态为green；number_of_nodes 节点个数为6；
二 节点重启
当修改配置文件，需要重启来生效时，而又不想影响集群的正常使用，可以按照下列方法
首先设置集群禁止分片
-
PUT /_cluster/settings -
{ -
"transient" : { -
"cluster.routing.allocation.enable" : "none" -
} -
}
然后，重启节点，重启后，恢复集群分片，如下设置
-
PUT /_cluster/settings -
{ -
"transient" : { -
"cluster.routing.allocation.enable" : "all" -
} -
}
因为正常情况下，Elasticsearch 希望你的数据被完全的复制和均衡的分布。如果你手动关闭了一个节点，集群会立刻发现节点的丢失并开始再平衡。如果节点的维护是短期工作的话，这一点就很烦人了，因为大型分片的再平衡需要花费相当的时间（想想尝试复制 1TB 的数据——即便在高速网络上也是不一般的事情了）。
三 推迟分片
上述是一个手动设置集群是否分片的过程，这里要讲的是，在一定的时间内延迟分片。
设置如下：
-
PUT /_all/_settings -
{ -
"settings": { -
"index.unassigned.node_left.delayed_timeout": "15m" -
} -
}
默认情况，集群会等待一分钟来查看节点是否会重新加入，如果这个节点在此期间重新加入，重新加入的节点会保持其现有的分片数据，不会触发新的分片分配。更改这个时间，达到你想要的效果。例如我们将时间设置成15分钟，在分钟之内，都不会触发新的分片；当然，失联节点的主分片对应的副本会被提拔成主分片；
如果节点在规定的时间内重新连接，首先会检查本地节点的数据是否是最新，如果最新则集群状态很快从yellow恢复到green；所以在延迟分片或者重启节点，最好不要写入数据；
如果节点在超时之后再回来，且集群还没有完成分片的移动，会发生什么事情呢？在这种情形下，Elasticsearch 会检查该机器磁盘上的分片数据和当前集群中的活跃主分片的数据是不是一样 — 如果两者匹配，说明没有进来新的文档，包括删除和修改 — 那么 master 将会取消正在进行的再平衡并恢复该机器磁盘上的数据。
之所以这样做是因为本地磁盘的恢复永远要比网络间传输要快，并且我们保证了他们的分片数据是一样的，这个过程可以说是双赢。
如果分片已经产生了分歧（比如：节点离线之后又索引了新的文档），那么恢复进程会继续按照正常流程进行。重新加入的节点会删除本地的、过时的数据，然后重新获取一份新的。
推迟分片可以解决上一篇中节点偶尔失联的问题。