默认是会用kibana的。下边的命令都是在kibana上执行的。
描述
我们对集群进行了升级，虽然已经将全部的数据都迁移到了新的集群上，但是由于之前文档不够充分，我们不能百分之百的保证之前的旧集群没有在使用。所以我们采用新老集群三个月内并存的方案。先直接退出两台机器，将数据分到其他的机器上。然后再关闭集群。只使用新集群，如果业务受到影响，就将旧集群恢复重启。
由于旧集群占用了过多的机器资源（六台机器，800G的内存），所以我们想要将机器从中释放两台。
注意事项
想要将机器退出集群，或者将节点退出集群。都应该关注一个问题，就是该节点是否是 master节点。比方说集群配置了最少需要三个具有master资格的节点。集群只有三个具备master资格的节点。此时你将一个master节点退出了，那么集群就失去了可用性。整个集群就完全不能使用了。
want 将节点退出集群
if（是master节点）{
if(一定要退出master这个节点){
需要重新修改集群的配置，配置该节点不具备master节点的资格。然后再重启集群，此时这个 节点就不是master节点了。可以退出。
}else{
选其他的非master节点退出
}
} 两套方案
- 利用es的自动恢复的机制。通过关闭集群中的机器，让master节点，自动的恢复。这个前提是需要机器有至少一个副本，才能保证不丢数据。
- 将机器排除到注册表之外。这种方案好处是不影响线上的继续使用，操作方便。只需要执行一个命令，剩下的就交给集群自己来完成。
方案一
步骤1：暂停数据写入程序
步骤2：关闭集群shard allocation
关闭集群分片自动分配
PUT _cluster/settings
{
"persistent": {
"cluster.routing.allocation.enable": "none"
}
} 步骤3：手动执行POST /_flush/synced 打开集群分片自动分配
POST /_flush/synced
步骤4：重启结点
步骤5：重新开启集群shard allocation
#打开集群分片自动分配
PUT _cluster/settings
{
"persistent": {
"cluster.routing.allocation.enable": "all"
}
} 步骤6：等待recovery完成，集群health status变成green
步骤7：重新开启数据写入程序
方案二
一开始的时候，我从官网上看到的这个api，担心es只是将这个台机器给排除在集群之外，会丢失数据。实际上不是，在调用这个api的时候，其实es不仅将这台机器给排除在外，并且将这上边的分片给分配到其他的节点上去了。
我在测试集群上进行了实验。测试通过以后，再在集群上进行操作最后成功将一台机器给分离出去。
操作步骤就一个，直接在kibana上执行下边的命令。
PUT _cluster/settings
{
"transient": {
"cluster.routing.allocation.exclude._ip":"10.10.2.254"
}
} 补充说明：因为我的需求是将一台机器完全的分离出去。所以我在调用api的时候，是直接将某个ip的节点全部从注册表剔除。
es 官网api给我们提供的还包括：将某个名字的节点给剔除出去。注意，如果你想把多个节点踢出去，这个api，只能一个一个踢出，踢出完了以后，还要吧节点停了。否则你先踢出了一个，然后踢出了第二个，第二个的分片还会到第一次踢出的节点上。
PUT _cluster/settings
{
"transient": {
"cluster.routing.allocation.exclude._name": "{nodeName}"
}
} 方案实施以及结果 最终采用第二套方案，因为我们的集群是没有副本的。不能使用第一个种方案。
第二种方案也更简单一点
结果展示：可以看到我们 254机器上已经没有任何数据了
再来看一下有数据的节点（其他正常使用的ip）：
看到节点上没有数据了以后，就可以将集群上的es实例给关闭了
最终看到结果
如何查看节点上有没有数据了：
先再kibana上点击左侧监控，然后点击右侧 Nodes 进去