ES无法重启问题分析

题背景：

对ES集群进行了重启，集群重启几分钟后，部分实例开始逐渐下线，导致集群不可恢复。

集群规模：

普通模式，3EsMaster，40EsNode，每实例均为31GB内存。

数据量：

1000多index,38365个shard，其中主分片28695个，数据量100T。

日志分析：

ES集群重启，恢复几分钟后，出现大量ping Master节点超时的错误，然后ES节点实例开始逐渐下线，导致集群恢复不了。

原因分析：

集群分片数过多，并发恢复过程中，同时业务没有停止，导致EsMaster处理压力过大，number_of_pending_tasks(挂起的任务)逐渐增加，到达4W多，大量的任务阻塞。

此时_cluster/health命令已无法正常返回结果，导致大量ES实例处于恢复中状态，连续3次检查超时后，Manger将会重启实例。就会导致挂起的任务越来越多，集群不可恢复。

处理步骤：

1. 重启的过程中，发现大量ES实例执行_cluster/health命令超时错误，但其实数据仍在缓慢恢复中。于是注释_cluser/health检查脚本，防止实例多次失败后，被manger重启。
2. 再次重启后，发现大量分片处于未分配状态，执行_cluster/allocation/explain查看分片未被分配的原因，发现shard恢复时的cluster.routing.allocation.node_current_incoming达到了最大值。鉴于集群主分片数太多，于是调大恢复参数至：cluster.routing.allocation.node_initial_primaries_recoveries 200 cluster.routing.allocation.node_concurrent_recoveries 100 cluster.routing.allocation.cluster_concurrent_rebalance 100 同时因为有业务数据写入，将分片分配设置为none:cluster.routing.allocation.enable none
3. 再次重启后，集群开始恢复，查看_cat/thred_pool/，generic 线程池（分片恢复会用到该线程池）已经到达128，查看界面CPU使用率也在70-80，查看日志，分片正在恢复中。
4. 10分钟左右，集群恢复到80%左右，开始恢复缓慢，初始化分片（initializing_shards）有2000多个，这些分片初始化的过程耗时接近2小时 原因分析：因为在多次重启的过程中，业务侧并没有停止，由于有些primary新写入了数据，在数据的recovery过程中，需要从主副本之间拷贝数据，或者利用translog恢复数据。直达primary-replica完全in-sync后，才会完成初始化。 这个过程取决于shard的大小和新写入量的大小（初始化的分片普遍数据量较大）。
   1. 最后有一个分片无法分配，查看原因，该分片无法从translog in-sync（同步），查看该索引settings，sync_interval设置为360s，设置同步刷新时间过多，会有一定几率发生数据丢失（客户有原数据备份）。
   2. 集群恢复后，还原集群参数配置和健康检查脚本。

问题根因：

1. 集群的分片数过多，按一个实例管理600shard为标准，该集群分片数过度超标的。合 理设置索引分片，定期对历史索引进行处理（关闭或删除不需要的索引）。
2. 目前的健康检查机制需要优化，使用_cluster/health去判断各实例的健康是否合理，包 括检查周期等。在EsMaster压力过大的情况下，_cluster/health可能会造成误判。