ELK系列——7.0.0 elasticsearch 集群部署踩坑记（四）
前言：最近es7系列版本出来了，玩了一下，发现之前的配置不管用了，看官方文档后发现，好些配置都改了。
开始按照以前的配置玩，启动后发现一直报警告日志：
master not discovered yet, this node has not previously joined a bootstrapped (v7+) cluster,
and [cluster.initial_master_nodes] is empty on this node
大概意思就是找不到主节点。
查询相关资料：
Elasticsearch 6.x 及之前的版本使用了一个叫作 Zen Discovery 的集群协调子系统。这个子系统经过多年的发展，成功地为大大小小的集群提供支持。然而，我们想做出一些改进，这需要对它的工作方式作出一些根本性的修改。
Zen Discovery 允许用户通过设置 discovery.zen.minimum_master_nodes 来决定多少个符合主节点条件的节点可以形成仲裁。在每个节点上一定要正确地配置这个参数，如果集群进行动态扩展，也需要正确地更新它，这一点非常重要。系统不可能检测到用户是否错误配置了这个参数，而且在实践当中，在添加或删除节点之后很容易忘记调整这个参数。Zen Discovery 试图通过在每次主节点选举过程中等待几秒来防止出现这种错误配置。这意味着，如果所选的主节点失败，在选择替代节点之前，集群至少在几秒钟内是不可用的。如果集群无法选举出一个主节点，有时候很难知道是为什么。
我们重新设计并重建了 Elasticsearch 7.0 的集群协调子系统：
- 移除 minimum_master_nodes 参数，让 Elasticsearch 自己选择可以形成仲裁的节点。
- 典型的主节点选举现在只需要很短的时间就可以完成。
- 集群的伸缩变得更安全、更容易，并且可能造成丢失数据的系统配置选项更少了。
- 节点更清楚地记录它们的状态，有助于诊断为什么它们不能加入集群或为什么无法选举出主节点。
在版本 6 和更早的版本中，还有一些其他以 discovery.zen.* 开头的选项，允许你配置 Zen Discovery 的行为。其中一些设置不再有效，已被删除。其他的已经改名。如果一个参数已经被改名，那么它的旧名称在版本 7 中就被弃用，你需要调整配置来使用新名称。
新的集群协调子系统包括一个新的故障检测机制。这意味着 discovery.zen.fd.* 开头的 Zen Discovery 错误检测设置不再有效。大多数用户应该在版本 7 或更高版本中使用默认的故障检测配置，如果需要进行任何更改，可以使用cluster.fault_detection.*
在新版7.0的es中，对es的集群发现系统做了调整，不再有discovery.zen.minimum_master_nodes这个控制集群脑裂的配置，转而由集群自主控制，并且新版在启动一个新的集群的时候需要有cluster.initial_master_nodes初始化集群列表。
最新的配置文件：
cluster.name: libbelasticsearch
node.name: "es128"
node.master: true
node.data: true
path.data: /opt/elasticsearch-7.0.0/data
path.logs: /opt/elasticsearch-7.0.0/logs
network.host: 192.168.1.128
transport.tcp.port: 9300
transport.tcp.compress: true
http.port: 9200
http.max_content_length: 100mb
bootstrap.memory_lock: true
discovery.seed_hosts: ["192.168.1.128","192.168.1.135","192.168.1.136"]
cluster.initial_master_nodes: ["192.168.1.128","192.168.1.135","192.168.1.136"]
gateway.recover_after_nodes: 2
gateway.recover_after_time: 5m
gateway.expected_nodes: 3