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

标签：redis   api   占用   多个   提升   学习   压力   recover   als   

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

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

标签：redis   api   占用   多个   提升   学习   压力   recover   als   

原文地址：http://www.cnblogs.com/zlslch/p/6619108.html