咱们一步步来拆解你的问题，先从Elasticsearch主节点选举的核心逻辑说起——不管是你在用的1.7版本，还是最新的8.x版本，核心规则是相通的，但细节上有一些差异：

Elasticsearch 1.7版本的情况 #

1. 1.7采用的是旧版Zen Discovery机制，只要当前活跃主节点（node-01）正常运行，集群不会触发重新选举——也就是说，node-01活着的时候，其他候选主节点（比如你要配置的node-02）不会抢主。
2. 但集群初始化/全量重启时是例外：此时所有节点同时启动，选举会遵循「优先选择节点ID更小的候选主」规则（节点ID是集群首次启动时自动生成的，除非手动指定）。如果node-01的ID比node-02小，它会被优先选为初始主；反之则有可能node-02当选。
3. 1.7没有强制指定主节点的配置项，只能通过启动顺序和节点ID来引导选举结果。

最新版本（如8.x）的情况 #

1. 新版本的集群协调机制更完善，同样遵循「当前主节点存活则不触发选举」的核心规则——node-01只要正常运行，就会一直担任活跃主。
2. 集群初始化阶段，你可以通过cluster.initial_master_nodes配置项指定初始候选主节点列表，明确让node-01成为第一个主节点；集群重启时，会优先恢复之前的活跃主节点身份，进一步降低其他候选主抢主的概率。
3. 即使是全新集群，选举也会优先选择节点ID更小的候选主，逻辑和1.7类似，但规则更稳定。

只有在以下场景下，node-02才会有机会当选活跃主：

• node-01出现故障（宕机、网络失联超过集群超时阈值），集群触发重新选举；
• 你手动触发主节点切换（比如通过API调用或者手动停止node-01）。

在所有节点正常运行的情况下，node-02绝对不会主动抢主，这点可以放心。

其实完全没必要担忧，原因有两个：

1. Elasticsearch的主节点选举机制就是为了高可用设计的——node-01正常时稳坐主位，出问题时node-02顶上去，反而能保证集群不中断；
2. 如果你真的想最大化让node-01优先当选，只需要在集群初始化/重启时，先启动node-01，等它成为主节点后再启动其他节点，这样后续加入的候选主不会发起选举。

要把node-02设为候选主节点，只需要修改它的elasticsearch.yml配置：

• 1.7版本：设置node.master: true（保留原有的node.data: true，因为它还是数据节点）；
• 最新版本：设置node.roles: [master, data]，同时确保cluster.initial_master_nodes包含node-01和node-02（如果是已运行的集群，不需要修改这个配置）。

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