Elasticsearch reading data using Java error Nonodeavailableexception:none of the configured nodes is available: [127.0.0.1:9300]

For this problem, most people appear in this place:

Client client = new TransportClient(settings).addTransportAddress(new InetSocketTransportAddress("172.16.2.13", 9300));?

The problem is that a new name was set for cluster when initializing Settings earlier, such as: Settings Settings = Immutablesettings.settingsbuilder (). Put ("Cluster.name", " Tonsonmiao "). Build ();

Because if ClusterName is set, the container will look for the IP and port to be set from the cluster name Tonsonmiao when adding transportaddress, so this error will be reported.

But I have this problem today, and before this all normal, that is not because the code error caused this problem, these days modified the next gateway, can access the server, so I think it may be the network changes, causing ES out of the problem, into the server to view:

[[email protected] elasticsearch-1.4.2]# ps-eaf |        grep javaroot 8782 8752 0 05:53 pts/1 00:00:00 grep javaroot 27251 1 1 2015? 1-10:15:49/USR/BIN/JAVA-XMS256M-XMX1G-XSS256K-DJAVA.AWT.HEADLESS=TRUE-XX:+USEPARNEWGC-XX:+USECONCMARKSWEEPGC- xx:cmsinitiatingoccupancyfraction=75-xx:+usecmsinitiatingoccupancyonly-xx:+heapdumponoutofmemoryerror-xx:+ Disableexplicitgc-dfile.encoding=utf-8-DELASTICSEARCH-DES.PATH.HOME=/OPT/ELASTICSEARCH-1.4.2-CP:/opt/ elasticsearch-1.4.2/lib/elasticsearch-1.4.2.jar:/opt/elasticsearch-1.4.2/lib/*:/opt/elasticsearch-1.4.2/lib/ sigar/* org.elasticsearch.bootstrap.elasticsearch[[email protected] elasticsearch-1.4.2]# NETSTAT-ANP |        grep 9300tcp 0 0 10.18.7.97:9300 10.17.3.96:51633 syn_recv-tcp  0 0 10.18.7.97:9300 10.17.3.96:51635 syn_recv-tcp 0 0            ::: 9300:::*            LISTEN 27251/java TCP 0 0:: ffff:10.18.7.97:41035:: ffff:10.18.7.97:9300 ES tablished 27251/java TCP 0 0:: ffff:10.18.7.97:9300:: ffff:10.18.7.97:41030 established 2725          1/java TCP 0 0:: ffff:10.18.7.97:41033:: ffff:10.18.7.97:9300 established 27251/java       TCP 0 0:: ffff:10.18.7.97:41037:: ffff:10.18.7.97:9300 established 27251/java TCP 0 0:: ffff:10.18.7.97:41036:: ffff:10.18.7.97:9300 established 27251/java TCP 0 0:: FFFF : 10.18.7.97:41026:: ffff:10.18.7.97:9300 established 27251/java TCP 0 0:: ffff:10.18.7.97:93           XX:: ffff:10.18.7.97:41025 established 27251/java

 

You can see that the IP address of the ES monitoring has changed, for the case of multiple network cards, ES by default will bind any one of the network card, if ES in the middle of the problem of automatic repair, then will randomly modify the binding network card, resulting in the node was t out of the cluster, I once in a banking system, encountered this problem, A certain number of nodes are out of the cluster when they are indeterminate.

For the resolution of this problem, the ES configuration needs to be modified:

# Set the bind address specifically (IPv4 or IPv6):#network.bind_host: 10.18.7.97# Set the address other nodes will use to communicate with this node. If not# set, it is automatically derived. It must point to an actual IP address.#network.publish_host: 10.18.7.97# Set both ‘bind_host‘ and ‘publish_host‘:#network.host: 10.18.7.97

Force the IP address to be specified

Elasticsearch reading data using Java error Nonodeavailableexception:none of the configured nodes is available: [127.0.0.1:9300]