My apologies, Jörg, for being confusing. *It's not a a matter of unicast vs. multicast or failure vs. non-failure.* >
Indeed, the node count and minimum master count are independent of the discovery mechanism. But the list of hostnames in the cluster is a matter of unicast; ES builds the list dynamically during multicast. > > *It's only the cluster admin who knows what the maximum number of nodes > is.* > Exactly. So what I was trying to say is, if the cluster admin has to count all the nodes, the cluster admin might as well write down the hostnames too. And then the cluster admin can use Chef or Puppet to send the list of host names in a unicast configuration to all nodes. And then my cool ES wrapper script picks up the list of hostnames, sets up the unicast discovery options using those names, automatically calculates the minimum number of nodes, and sets up that config option too. The ES starts with the best chance to prevent a split-brain situation. I hope that is clearer. As a follow on, one of the uses of ES is for a QA verification tool to emulate a production server but in a very lightweight (though fully functional) way. To that end, during the startup there is a preload step to ensure that a certain index is populated but to not reload if it already exists. And it uses the unicast host name list to determine that if there is only one host the preload step can be done automatically when the cluster first starts. But if there are two or more nodes in the cluster, the preload step is not done automatically. One more reason to prefer unicast over multicast! Brian -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/9a177d63-fb9e-4e05-aefe-a9368d481021%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
