集群准备

elasticsearch elasticsearch-7.13.2-linux-x86_64.tar.gz
kibana kibana-7.13.2-linux-x86_64.tar.gz

因为我本地是虚拟机

解压出来
elk/elasticsearch-7.13.2
elk/elasticsearch-7.13.2-2
elk/elasticsearch-7.13.2-3

分别配置config/elasticsearch.yml

cluster.name : es #集群的名字都一样
node.name: node-3 #这里分别起各自的名字
network.host: 192.168.116.128 #本地地址
port: 9202 #默认端口是9200，分别设置为9200 9201 9202 因为是在同一台机器
path.data: /opt/data/node3 #es的索引数据存储的目录，尽量不要放在es的包里，
升级es的时候可能被清理掉
path.logs: /var/logs/es-node3 #es的日志文件存放地址
discovery.seed_hosts: ["192.168.116.128:9300",
                       "192.168.116.128:9301",
                       "192.168.116.128:9302"]
#初始化一个新的集群时需要此配置来选举master，此设置应该是群集中所有候选主节点的地址的列表
cluster.initial_master_nodes: ["node-1","node-2","node-3"]
#写入候选主节点的名字，在开启服务后可以被选为主节点

transport.tcp.port : 9300 # 内部节点之间沟通端口，REST 客户端通过 HTTP 将请求发送到您的
Elasticsearch 集群，但是接收到客户端请求的节点不能总是单独处理它，通常必须将其传递给其他
节点以进行进一步处理。它使用传输网络层（transport networking layer）执行此操作。
传输层用于集群中节点之间的所有内部通信，与远程集群节点的所有通信，
以及 Elasticsearch Java API 中的 TransportClient。

node.master: true
node.data: true

配置kibana下的config/kibana.yml
server.port: 5601
server.host: "192.168.116.128"
server.name: "Jack kibana"
elasticsearch.hosts: ["http://192.168.116.128:9200",
"http://192.168.116.128:9201",
"http://192.168.116.128:9202"]

elasticsearch.username: "kibana_system"
elasticsearch.password: "liritian"

来吧我们实际操作一下，实践是检验真理的唯一标准
依次启动
elk/elasticsearch-7.13.2/bin/elasticsearch
elk/elasticsearch-7.13.2-2/bin/elasticsearch
elk/elasticsearch-7.13.2-3/bin/elasticsearch

这里省略几小时………
在kibana的监控器里可以看到

3个节点都ok，其中五角星的代表是主节点，master节点是 node-1
启动记录日志上看：
[node-2] master node changed {previous [], current [{node-1}{EFLnLz4ER8SCpzWq-takFQ}{8ZlUChycQwOtWQLxHT3Tzw}{192.168.116.128}{192.168.116.128:9300} 当前的主节点是node-1

点开其中1个看具体情况

节点加入

复制一份为elk/elasticsearch-7.13.2-4/bin/elasticsearch
配置跟上述一样

在新窗口启动第4个节点，注意观察node-1的记录

可见当node-4启动之后，就自动加入cluster了，新窗口显示如下图

这个时候在kibana里面看到的情况有些变化

节点退出

非主节点退出
我先把node-4退出

主节点显示：
[node-1] removed {{node-4}{TkMRLpCTS7G7o3L4WgEmpA}{wijfy3GjSDWIbN5gB2ZurQ}{192.168.116.128}{192.168.116.128:9303}{cdfhilmrstw}}, term: 2, version: 99, reason: Publication{term=2, version=99}

主节点退出
我先把node-4加入，再把node-1退出

从结果上来看是node-3当选了主节点

把node-2 设置为候选主节点，node-3，node-4 是不是就不能参加竞选了？

修改node-3和node-4的elasticsearch.yml下的配置为
node.master: false
4个节点的配置
cluster.initial_master_nodes: ["node-1","node-2"] 把node-3取消
依次重启4个节点
结果：炸了，启动不了了，
猜测：选举的节点只有俩，无法达到 n/2+1的条件

问题

1 failed to flush export bulk [default_local]
是因为没有配置ingest节点
2 Main.cc@106 Parent process died - ML controller exiting
这里搜索下来是 需要新建一个用户
useradd elastic
passwd elastic

chow -R elk/elasticserach-7.13.2
chow -R elk/elasticserach-7.13.2-2
chow -R elk/elasticserach-7.13.2-3

3 单虚拟机，启动3个节点，只有2个节点起作用，启动第3个会挤掉另外一个？重启会轮流挤掉，现象就是killed 也不知道为什么会killed。
配置有问题，就这个鬼玩意，弄了好久哦，我开始以为是java的jvm内存不够，后面也没找个所以然，然后我把配置配成如下，才启动起来

cluster.name: es
node.name: node-1
path.data: /opt/data/node1
path.logs: /opt/logs/node1
network.host: 0.0.0.0
network.bind_host: 192.168.116.128
network.publish_host: 192.168.116.128

http.port: 9200
discovery.seed_hosts: ["192.168.116.128:9300","192.168.116.128:9301","192.168.116.128:9302"]
cluster.initial_master_nodes: ["node-1","node-2","node-3"]
node.max_local_storage_nodes: 3
transport.tcp.port: 9300
http.cors.enabled: true
http.cors.allow-origin: "*"
discovery.zen.fd.ping_timeout: 5m
discovery.zen.fd.ping_retries: 5
node.master: true

4 问题4 vm.max_map_count 的太小

查看sudo sysctl -a|grep max_map_count
修改 vim /etc/sysctl.conf
方法1 增加一行 vm.max_map_count=xxxx（显示错误要求配置的最小值）推荐方法
方法2 sysctl -w vm.max_map_count=262144 不建议这么修改，关闭虚拟机就还是原来的值了

5 不能配置了node.roles: [master] 又配置node.master: true,会报错的。

其余配置

恢复配置

gateway.recover_after_nodes: 8 Elasticsearch 在存在至少 8 个节点（数据节点或者 master 节点）之前进行数据恢复
gateway.expected_nodes: 10
gateway.recover_after_time: 5m

• 等待集群至少存在 8 个节点
• 等待 5 分钟，或者10 个节点上线后，才进行数据恢复，这取决于哪个条件先达到