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

场景:

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

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

es (brain split)脑裂问题导致重建索引速度缓慢_第1张图片

问题排查:

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

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

于是两个怀疑

1. mysql的响应慢

2. es的写入慢

3. 网络通信问题(最低可能)

 

针对怀疑1:

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

es (brain split)脑裂问题导致重建索引速度缓慢_第2张图片

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

 

针对怀疑2:

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

不看不知道,一看吓一跳

es (brain split)脑裂问题导致重建索引速度缓慢_第3张图片

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

解决:

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

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

 

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

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

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

[2020-03-16T10:50:45,486][ERROR][o.e.t.n.Netty4Utils      ] fatal error on the network layer

[2020-03-16T10:51:39,725][ERROR][o.e.b.ElasticsearchUncaughtExceptionHandler] fatal error in thread [elasticsearch [search][T#5]], exiting

java.lang.OutOfMemoryError: Java heap space

[2020-03-16T10:52:00,975][ERROR][o.e.b.ElasticsearchUncaughtExceptionHandler] fatal error in thread [Thread-510337], exiting

java.lang.OutOfMemoryError: Java heap space

 

你可能感兴趣的:(ELK)