es (brain split)脑裂问题导致重建索引速度缓慢_fatal error in thread

场景：

线上使用两台es主机，6.2.4版本，组成集群（为什么是两台，这就是历史遗留问题了......）

使用logstash-jdbc同步数据库中的数据到es（定时重建索引任务），原本只需要1到2秒的时间，现在居然1min（logstash抓取modify_time字段的时间间隔）仅仅同步了部分数据

问题排查：

查看logstash日志，其已经向mysql发出了执行请求

查看es日志，没有什么特别的异常（这里实际上有问题，因为es日志是每天归档的，我只是看了几天的日志）

于是两个怀疑

1. mysql的响应慢

2. es的写入慢

3. 网络通信问题（最低可能）

 

针对怀疑1：

现在服务器上使用tcpdump抓包，看一下mysql的响应情况

通过tcp追踪流，发现mysql响应正常

 

针对怀疑2：

怎么看es的写入速度情况呢？先看一下集群索引情况

不看不知道，一看吓一跳

那么问题就清楚了，这两台es主机发生了脑裂，各自都成为了一个集群，而kibana是连接在其中一台机器上，只能看到这台机器的情况

解决：

逐个重启两台es，其重新建立集群，好在数据似乎合并起来并没啥问题

有一些重要数据是replica=1的，有一些数据是replica=0的

 

1. 之前疏忽对集群健康的监控，准备加入到prometheus metrics指标中

2. 加入一台，扩容为三台，避免发生脑裂问题

3. 追踪es日志，最后发现之前某台机器es由于OOM重启过一次，而在重启之后，就脑裂了