公司内部使用elasticsearch已经有一年以上了，主要为后台检索提供服务，我们的视频有千万级别的数据量。
一些复杂的检索需求通过es很容易的就能很好的支持。相对其他组件来说还算稳定，中间也出现过一些小故障，通过网上提供的解决方案都顺利的解决掉。
首先简要说明下es插件，我们用了head和bigdesk两个插件。
本次故障原起是因发现了es插件bigdesk中有一台主机采集不到监控数据，另外两台监控采集数据是正常的。
查询了日志，从5-30号之后因为一个索引分片未成功，导致这台机器未正常采集到监控数据，通过head插件将该索引关闭，这里无法彻底删除索引，所以登录服务器将索引文件删除。
尝试将问题机器10.130.91.74进行重启，但是重启过程总是提示9380端口被占用。
本机上通过命令 lsof -i:9380进行查看，发现确实存在占用9380端口的进程，然后暂时将其kill掉。之后，继续重启，但是仍然提示端口被占用，继续lsof查看并未发现有进程占用该端口了。
org.elasticsearch.transport.BindTransportException: Failed to bind to [9380]
at org.elasticsearch.transport.netty.NettyTransport.bindServerBootstrap(NettyTransport.java:422)
at org.elasticsearch.transport.netty.NettyTransport.doStart(NettyTransport.java:283)
at org.elasticsearch.common.component.AbstractLifecycleComponent.start(AbstractLifecycleComponent.java:85)
at org.elasticsearch.transport.TransportService.doStart(TransportService.java:153)
at org.elasticsearch.common.component.AbstractLifecycleComponent.start(AbstractLifecycleComponent.java:85)
at org.elasticsearch.node.internal.InternalNode.start(InternalNode.java:257)
at org.elasticsearch.bootstrap.Bootstrap.start(Bootstrap.java:160)
at org.elasticsearch.bootstrap.Bootstrap.main(Bootstrap.java:248)
at org.elasticsearch.bootstrap.Elasticsearch.main(Elasticsearch.java:32)
Caused by: org.elasticsearch.common.netty.channel.ChannelException: Failed to bind to: /10.130.91.92:9380
at org.elasticsearch.common.netty.bootstrap.ServerBootstrap.bind(ServerBootstrap.java:272)
at org.elasticsearch.transport.netty.NettyTransport$1.onPortNumber(NettyTransport.java:413)
at org.elasticsearch.common.transport.PortsRange.iterate(PortsRange.java:58)
at org.elasticsearch.transport.netty.NettyTransport.bindServerBootstrap(NettyTransport.java:409)
8 more
Caused by: java.net.BindException: Cannot assign requested address
at sun.nio.ch.Net.bind0(Native Method)
at sun.nio.ch.Net.bind(Net.java:444)
at sun.nio.ch.Net.bind(Net.java:436)
at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:214)
at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
at org.elasticsearch.common.netty.channel.socket.nio.NioServerBoss$RegisterTask.run(NioServerBoss.java:193)
at org.elasticsearch.common.netty.channel.socket.nio.AbstractNioSelector.processTaskQueue(AbstractNioSelector.java:391)
at org.elasticsearch.common.netty.channel.socket.nio.AbstractNioSelector.run(AbstractNioSelector.java:315)
at org.elasticsearch.common.netty.channel.socket.nio.NioServerBoss.run(NioServerBoss.java:42)
at org.elasticsearch.common.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:108)
at org.elasticsearch.common.netty.util.internal.DeadLockProofWorker$1.run(DeadLockProofWorker.java:42)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
[2017-07-21 16:03:55,598][INFO ][node ] [10.130.91.74] stopping
[2017-07-21 16:03:55,602][INFO ][node ] [10.130.91.74] stopped
[2017-07-21 16:03:55,603][INFO ][node ] [10.130.91.74] closing
[2017-07-21 16:03:55,614][INFO ][node ] [10.130.91.74] closed
实际根本原因是因es配置文件中一个很关键的属性配置有误导致，network.host配置成了其他node的IP，因为其他node正常运行中，9280、9380端口都是被占用的，所以会提示这个错误。但是配置过程中并没有注意到network.host不是本机IP，直接修改了如下两个参数：
network.bind_host: 0.0.0.0
network.publish_host: 10.130.91.92
修改之后，es服务确实能够启动了，但是此时就出现整个集群挂了，无法提供服务，汗呀！
主要原因还是因为没有明白这些参数的含义贸然修改导致的故障。
后来将配置回滚回去，对照其他es节点的配置，将network.host修改为本机IP，如果不配置则默认是localhost，启动之后发现集群仍然无法使用。
我们根据10.130.91.92上的es如下日志：
[2017-07-21 16:00:25,882][INFO ][cluster.service ] [10.130.91.92] removed {[10.130.91.74][EqwqlgtMSXORr1XVovSABw][cdn.oss.letv.com][inet[/10.130.91.74:9380]]{master=true},}, reason:
zen-disco-node_failed([10.130.91.74][EqwqlgtMSXORr1XVovSABw][cdn.oss.letv.com][inet[/10.130.91.74:9380]]{master=true}), reason transport disconnected
[2017-07-21 16:00:26,024][INFO ][cluster.routing ] [10.130.91.92] delaying allocation for [44] unassigned shards, next check in [59.8s]
[2017-07-21 16:11:35,764][WARN ][discovery.zen ] [10.130.91.92] received join request from node [[10.130.91.74][f5SwMbYxTKyxBmiOHpqFGw][cdn.oss.letv.com][inet[/10.130.91.92:9380]]
{master=true}], but found existing node [10.130.91.92][DYSZfClbQVaJj8CpofIb_g][cdn.oss.letv.com][inet[/10.130.91.92:9380]]{master=true} with same address, removing existing node
[2017-07-21 16:11:35,764][INFO ][cluster.service ] [10.130.91.92] removed {[10.130.91.92][DYSZfClbQVaJj8CpofIb_g][cdn.oss.letv.com][inet[/10.130.91.92:9380]]{master=true},}, added {
[10.130.91.74][f5SwMbYxTKyxBmiOHpqFGw][cdn.oss.letv.com][inet[/10.130.91.92:9380]]{master=true},}, reason: zen-disco-receive(join from node[[10.130.91.74][f5SwMbYxTKyxBmiOHpqFGw][cdn.oss.let
v.com][inet[/10.130.91.92:9380]]{master=true}])
[2017-07-21 16:12:05,766][WARN ][discovery.zen.publish ] [10.130.91.92] timed out waiting for all nodes to process published state [327] (timeout [30s], pending nodes: [[10.130.91.74][f5S
wMbYxTKyxBmiOHpqFGw][cdn.oss.letv.com][inet[/10.130.91.92:9380]]{master=true}])
[2017-07-21 16:12:05,767][INFO ][cluster.routing ] [10.130.91.92] delaying allocation for [0] unassigned shards, next check in [0s]
[2017-07-21 16:12:05,768][DEBUG][action.admin.cluster.node.stats] [10.130.91.92] failed to execute on node [D-n-v9E7TgKe8QEkD_en6w]
java.lang.NullPointerException
根据日志能看到：
从10.130.91.74机器收到了请求，启用了10.130.91.92:9380端口，但是，发现是10.130.91.92机器上存在了相同的地址，然后集群将10.130.91.92机器removing existing node从集群中删除掉了。
目前情况是三台机器，2台不可用，1台可用，但是没办法选举master了，因为配置中discovery.zen.minimum_master_nodes: 2 选举master至少有2台节点存活才可以。所以，现在是群龙无首了。
最后，将网络配置恢复正常，依次重启每一台服务器，es集群重新选举master，集群由red状态变为了green，服务可用。
es网络参数配置说明：
设置绑定的ip地址，可以是ipv4或ipv6的，默认为0.0.0.0。
network.bind_host: 192.168.0.1
设置其它节点和该节点交互的ip地址，如果不设置它会自动判断，值必须是个真实的ip地址。
network.publish_host: 192.168.0.1
这个参数是用来同时设置bind_host和publish_host上面两个参数。
network.host: 192.168.0.1
总结：
主要原因还是不够细心+对配置不熟，实际端口被占用，日志中已经很明显的体现出来了。
通读和理解所有的配置参数，做到心中有数，后续再遇到问题时，切记要冷静处理，详细读取每一行日志，头脑要清晰。
同时，也因为这次故障汲取到一些经验，知道了当网络配置错误引起的问题以及es在这个过程中做了哪些事情。
参考资料：
posted on 2017-07-24 19:10
David1228 阅读(11369)
评论(0) 编辑 收藏 所属分类:
JAVA 、
J2EE 、
ES