Elasticsearch之es学习工作中遇到的坑（陆续更新）

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、后续更新