公司內部使用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 閱讀(11391)
評論(0) 編輯 收藏 所屬分類:
JAVA 、
J2EE 、
ES