1：es集群脑裂问题(不要用外网ip，节点角色不要混用)

原因1：阿里云服务器，外网有时候不稳定。

解决方案：单独采购服务器，内网安装

原因2：master和node节点没有分开

解决方案：

分角色：master节点(三台)，data节点(随着数据增加而增加)，client(随着查询压力而增加)节点

Master节点：node.master: true   node.data: false

Data节点：node.master: false   node.data: true

Client 节点：node.master: false   node.data: false

2：es集群名称的坑(1.4.x版本)

之前在使用1.4版本的时候，这个版本默认是多播协议，可以自动把同一网段的es节点组成一个集群。

所以，在刚开始使用的时候，多种业务部署了多个es集群，结果发现这几个集群莫名其妙搞到一块了。

建议：尽量不要使用集群的默认名称。

不过在2.x的版本中已经默认开启单播协议，不会自动增加同一网段的节点到一个集群。但是也建议修改一下集群名称，改完之后，如果使用java api进行操作，则必须设置cluster.name属性。

3：数据平衡，数据恢复(recover)

假设一个有10个节点的集群。

当重启集群的时候，在启动第二个节点的时候，集群之内的两个节点就开始恢复数据，相互生成副本，当启动第三个节点的时候，这三个节点又重新对数据进行恢复...........

这样非常浪费性能，导致在启动集群的过程当中，做了很多无用功，所以可以设置，当启动集群中5~6个节点的时候再允许进行数据恢复。

建议设置为集群节点数量的一半以上。

gateway.recover_after_nodes: 5

还有一点：es集群要使用内网ip，否则会出现数据恢复缓慢的现象。

4：定时优化索引片段很重要

开始的时候，没有对索引片段进行优化，查询延迟在3S以上，索引优化之后，延迟时间立刻降到1S以内。

5：内存溢出

修改elasticsearch.in.sh脚本

Master节点内存占用不多，CPU稍微高一点。

Data节点内存占用比较多，io操作比较频繁

Client：CPU和内存占用比较平均

6：集群插入数据报错

集群状态为yellow，索引副本数设置为2，但是只有一个节点存活，也就是没有产生副本。插入数据时报错。

7：设置jvm锁住内存时启动警告

当设置bootstrap.mlockall: true时，启动es报警告Unknown mlockall error 0，因为linux系统默认能让进程锁住的内存为64k。

解决方法：设置为无限制，linux命令：ulimit -l unlimited(立刻生效)

或者修改/etc/security/limits.conf(下一次重启开始，永久有效)文件

8：elk中，redis中数据堆积严重

调整logstash内存，使用批量方式向es中索引数据。

9：横向扩展es集群，不要纵向扩展

单纯增加es节点的内存和CPU不会有很大提升，建议多增加节点。

10：目前es集群部署情况

Master：3台(4 core ,16G内存,500G)

192.168.1.20

192.168.1.21

192.168.1.22

Data：8台(4 core 32G内存,2x1T)

192.168.1.31

192.168.1.32

192.168.1.33

192.168.1.34

192.168.1.35

192.168.1.36

192.168.1.37

192.168.1.38

Client：3台(4 core,32G,500G)

192.168.1.10

192.168.1.11

192.168.1.12

11、后续更新