1
votes

I have 2 instances of hz running in ip1 and ip2. The configuration for hazelcast looks like below :

Config config = new Config();

config.getGroupConfig().setName("dev");
config.getGroupConfig().setPassword("dev");

config.getNetworkConfig().getJoin().getTcpIpConfig().setEnabled(true);
config.getNetworkConfig().getJoin().getMulticastConfig().setEnabled(false);
config.getNetworkConfig().getJoin().getAwsConfig().setEnabled(false);
config.getNetworkConfig().getJoin().getTcpIpConfig().addMember(ip1).addMember(ip2);

config.getNetworkConfig().setInterfaces(new InterfacesConfig().setEnabled(true).addInterface(ip1).addInterface(ip2));

return Hazelcast.newHazelcastInstance(config);

Now I have another instance running at ip3 with same config but ip3 is added to the tcp member

config.getNetworkConfig().getJoin().getTcpIpConfig().addMember(ip1).addMember(ip2).addMember(ip3);

I was expecting the instance ip3 to either fail or not join the cluster since the configuration is not matching but they are all able to find each other and form a cluster.

How can I avoid this scenario? Should I set some property to reject a node from cluster formation if there is any mismatch in the config?

Because with this scenario, all I need to know is the group name and one of the cluster member. I can easily join the cluster and modify/delete the cache right?

1

1 Answers

1
votes

Hazelcast members and clients need AT LEAST one entrypoint into the cluster, that said, ANY IP address of a cluster member with matching groupname and grouppassword can act as such an entrypoint. Why would you put all IPs into every node if they are not supposed to connect?

In general it is recommended to use a discovery service like eureka, zookeeper, etcd, ... which is way more flexible than setting up fixed ip-addresses.