es迁移分片，重置主节点。

问题描述

es部署后可能因为配置原因导致es节点不在集群中，但是进程依然存在。

现在已下面5台机器作为测试演练

一开始按照之前的es部署方案，会在5台中选择一台作为主节点，当然该节点也充当了数据节点的功能。

第一步：（22,23,24,25,26分别对应图中的06-10机器）

在5台机器上部署成功后，一开始23为主节点。（这时候23推选为主节点，也充当了数据节点。所以22,23,24,25,26节点上有数据）.

第二步：

我们将22,24,26上的分片手动迁移到23,25上，这个时候22，24，26上就没有数据了。（规划：22,24作为主节点 23,25作为数据节点 26作为协调节点。）

迁移数据

elasticsearch可以通过reroute api来手动进行索引分片的分配。

不过要想完全手动，必须先设置cluster.routing.allocation.disable_allocation的值

具体设置参考该值的设置以及解释

官网上的解释官网配置

curl -XPUT 172.18.1.22:9200/_cluster/settings -d'{
"transient": {
"cluster.routing.allocation.enable": "none"
}
}'

迁移完记得改回来该值

curl -XPUT 172.18.1.22:9200/_cluster/settings -d'{
"transient": {
"cluster.routing.allocation.enable": "all"
}
}'

迁移具体的分片到其他节点上去。

curl -XPOST '172.18.1.22:9200/_cluster/reroute' -d  '{
"commands" : [
{
"move" : {
"index" : "info-test", "shard" : 3,
"from_node" : "172.18.1.26", "to_node" : "172.18.1.25"
}
}
]
}'

该指令意思是将26上的info-test索引的3这个分片迁移到25机器上去

当所有的分片都迁移完就会出现下图这样

第三步：

修改了配置将22,24作为主节点， 23,25作为数据节点 ，26作为协调节点，重启服务后。

具体的设置只是添加了node.master和node.data的值。看了下面的相信你就知道怎么设置了。引用了别人博客中的内容node.master详解

在生产环境下，如果不修改elasticsearch节点的角色信息，在高数据量，高并发的场景下集群容易出现脑裂等问题。
默认情况下，elasticsearch集群中每个节点都有成为主节点的资格，也都存储数据，还可以提供查询服务。
这些功能是由两个属性控制的。
node.master和node.data
默认情况下这两个属性的值都是true。
下面详细介绍一下这两个属性的含义以及不同组合可以达到的效果。
node.master：这个属性表示节点是否具有成为主节点的资格
注意：此属性的值为true，并不意味着这个节点就是主节点。
因为真正的主节点，是由多个具有主节点资格的节点进行选举产生的。
所以，这个属性只是代表这个节点是不是具有主节点选举资格。
node.data：这个属性表示节点是否存储数据。
这两个属性可以有四种组合：
第一种：这种组合表示这个节点即有成为主节点的资格，又存储数据，
这个时候如果某个节点被选举成为了真正的主节点，那么他还要存储数据，这样对于这个节点的压力就比较大了。
elasticsearch默认每个节点都是这样的配置，在测试环境下这样做没问题。实际工作中建议不要这样设置，
这样相当于主节点和数据节点的角色混合到一块了。
node.master: true
node.data: true
第二种：这种组合表示这个节点没有成为主节点的资格，也就不参与选举，只会存储数据。
这个节点我们称为data(数据)节点。在集群中需要单独设置几个这样的节点负责存储数据。后期提供存储和查询服务。
node.master: false
node.data: true
第三种：这种组合表示这个节点不会存储数据，有成为主节点的资格，可以参与选举，有可能成为真正的主节点。
这个节点我们称为master节点
node.master: true
node.data: false
第四种：这种组合表示这个节点即不会成为主节点，也不会存储数据，
这个节点的意义是作为一个client(客户端)节点，主要是针对海量请求的时候可以进行负载均衡。
node.master: false
node.data: false
默认情况下，每个节点都有成为主节点的资格，也会存储数据，还会处理客户端的请求。
在一个生产集群中我们可以对这些节点的职责进行划分。
建议集群中设置3台以上的节点作为master节点【node.master: true node.data: false】
这些节点只负责成为主节点，维护整个集群的状态。
再根据数据量设置一批data节点【node.master: false node.data: true】
这些节点只负责存储数据，后期提供建立索引和查询索引的服务，这样的话如果用户请求比较频繁，这些节点的压力也会比较大
所以在集群中建议再设置一批client节点【node.master: false node.data: true】
这些节点只负责处理用户请求，实现请求转发，负载均衡等功能。
master节点：普通服务器即可(CPU 内存 消耗一般)
data节点：主要消耗磁盘，内存
client节点：普通服务器即可(如果要进行分组聚合操作的话，建议这个节点内存也分配多一点)

重启后我们会发现master节点已经变了，并且第二幅图我们也可以看到节点充当了什么角色



mi主节点 di数据节点 iclient节点



注意：如果有分片迟迟无法分配，可使用es reroute api(官网说明)手动重试分配，操作如下：

curl -XPOST ‘192.168.14.148:9200/_cluster/reroute?retry_failed’

总结：如果在线上出现需要改变主节点或者主节点上有数据需要迁移到其他节点上，可以尝试上面操作。