elasticsearch进阶（二）错误问题汇总

这篇文章用来记录从今起（2018/7/1）开始，elasticsearch遇见的错误。

2018/7/1

以下三条记录源于5台机器导入近3亿条文档

1.集群压力大，某台机器失去“心跳”后，其他机器好像总找不回它，导致数据无法继续传输
这里写图片描述
查看日志，是说9300拒绝连接，想不明白，怎么会拒绝连接？很显然与防火墙无关，果然，关了防火墙依然有出现这种情况的可能。
【我感觉还是9300的写入压力太大？】

目前既没有找到好的解释，也没有好的解决办法
目前的解决办法是：
将bulk提交的request——timeout设置得很大，比如600秒，retries数也设置大一些，比如说100次。这样一来，集群不可用时，自己的代码程序不会退出。因为代码退出代价很大，你不知道什么时候集群失效了，数据传输到了哪些文件的哪些位置，重来又太耗时。
故让代码持续的去尝试请求，然后手动修复集群。

2.[WARN ][o.e.m.j.JvmGcMonitorService] [es-ip13] [gc][160] overhead, spent [97
这是个小坑，设置初始堆和最大堆的值后（我是12g），需要将下方的默认的1g注销掉，否则还是会设置为1G【你可以在启动es时，在其日志中查看到，会有12g，12g，1g, 1g的打印；或者从kibana中通过监控界面看到，你会看到，应用不断的GC】
即使你是Python客户端，也不应该忘记，ES是Java程序，不要忘了JVM和GC
这里写图片描述

可以看到，至少在批量导入数据时，内存占用还是很高的。

2018/08/14

netty版本冲突
java.lang.NoSuchMethodError: io.netty.util.AttributeKey.newInstance(Ljava/lang/String;)Lio/netty/util/AttributeKey;
最开始只看见log4j依赖包冲突：

<dependency>
            <groupId>org.elasticsearch</groupId>
            <artifactId>elasticsearch</artifactId>
            <version>${elasticsearch.version}</version>
            <exclusions>
                <exclusion>
                    <groupId>org.apache.logging.log4j</groupId>
                    <artifactId>log4j-api</artifactId>
                </exclusion>
            </exclusions>
        </dependency>

运行依然同样的报错：
这里写图片描述
可以发现，netty确实有低版本冲突

通过这种方式排除冲突依赖是不大合适了，这么多，看不过来。
一大堆博客都这样写，尼玛你认为这真的是个好办法？上百个依赖关系，要不你使用3个屏幕接起来放大慢慢看？
这里写图片描述
解决办法：
插件Maven Helper

使用示例：

        <dependency>
            <groupId>org.apache.hbase</groupId>
            <artifactId>hbase-client</artifactId>
            <version>1.2.0</version>
            <exclusions>
                <exclusion>
                    <artifactId>netty</artifactId>
                    <groupId>io.netty</groupId>
                </exclusion>
                <exclusion>
                    <artifactId>netty-all</artifactId>
                    <groupId>io.netty</groupId>
                </exclusion>
            </exclusions>
        </dependency>