Elastic Search集群模式触发java.lang.RuntimeException，单节点正常

Let's break down the most common causes and actionable fixes for this issue, since your setup works perfectly in single-node mode but hits this error when switching to a cluster:

1. Verify Inter-Node Network Connectivity #

Cluster nodes depend on port 9300 (default) for inter-node communication. If this port is blocked or nodes can't reach each other, you'll get generic request failures.

• Test connectivity between nodes with these commands:

  # Replace <node-ip> with another cluster node's IP
  telnet <node-ip> 9300
  # Or use nc if telnet isn't installed
  nc -zv <node-ip> 9300
  

• Ensure firewalls (iptables, ufw, cloud security groups) allow inbound/outbound traffic on port 9300 between all cluster nodes.

2. Validate Cluster Configuration Consistency #

All nodes in the cluster must have matching critical settings in elasticsearch.yml:

• Confirm cluster.name is identical across all nodes (yours is mdesk-api):

  cluster.name: mdesk-api
  

• Each node needs a unique node.name (no duplicates allowed):

  node.name: node-1 # Use node-2, node-3, etc. for other nodes
  

• Set discovery.zen.ping.unicast.hosts to list all cluster nodes (mandatory for 6.x's Zen discovery, skipped in single-node mode):

  discovery.zen.ping.unicast.hosts: ["<node-1-ip>", "<node-2-ip>"]
  

3. Check Node Permissions & System Limits #

Elasticsearch requires specific system permissions to run reliably in cluster mode:

• Ensure the elasticsearch user has read/write access to data and log directories:

  sudo chown -R elasticsearch:elasticsearch /var/lib/elasticsearch/ /var/log/elasticsearch/
  

• Increase file descriptor limits (ES needs at least 65535):
  Add these lines to /etc/security/limits.conf:

  elasticsearch soft nofile 65535
  elasticsearch hard nofile 65535
  

  Then restart the Elasticsearch service.

4. Dig Into Elasticsearch Logs #

The generic RuntimeException hides the real issue—check node logs for detailed errors:

• View the latest logs with:

  tail -f /var/log/elasticsearch/mdesk-api.log
  

  Look for ERROR-level messages like:
  • failed to join cluster
  • timeout connecting to node
  • permission denied
    These will pinpoint exactly what's breaking cluster communication.

5. Validate Client Configuration #

Make sure your client is set up for cluster mode:

• Connect to multiple cluster nodes (not just one) to handle failover:

  // Example Java client setup for cluster
  RestClient restClient = RestClient.builder(
    new HttpHost("<node-1-ip>", 9200, "http"),
    new HttpHost("<node-2-ip>", 9200, "http")
  ).build();
  

• Confirm the client's Elasticsearch version matches the server (6.1.1)—version mismatches can cause unexpected request failures.

6. Check JVM & System Resources #

Cluster nodes need sufficient memory to maintain communication and process data:

• Verify JVM heap settings in jvm.options are reasonable (avoid allocating more than 50% of system RAM, max 32GB):

  -Xms4g
  -Xmx4g
  

• Use top or htop to check for high CPU/memory usage—resource exhaustion can prevent nodes from responding to requests.

Start with checking logs and network connectivity first—those are the most likely culprits when moving from single-node to cluster mode.

内容的提问来源于stack exchange，提问作者Vasantha Raj