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、后续更新
本文转自大数据躺过的坑博客园博客，原文链接：http://www.cnblogs.com/zlslch/p/6619108.html，如需转载请自行联系原作者
