es集群节点加入失败join validation on cluster state with a different cluster uuid...than local cluster uuid..

本来之前已经将es集群搭建完成了，但是不小心使用rm -rf /var/lib把文件删除了，我本来只想删除/var/lib下的一个文件夹的，结果删错了，整个集群没了，这，，，，还好集群上跑的都是一些测试数据，但是重新搭建也是废了一番功夫。有关防止rm -rf误删的方法我在另一篇博客中有提及待补充博客链接，大家可以做个参考。

搭建elasticsearch集群的步骤我在这篇博客:"https://blog.csdn.net/m0_49984184/article/details/108181812 k8s集群搭建efk集群日志收集系统"中介绍过，事情是这样的(我写博客喜欢把事情的前因后果介绍一下，因为我觉得这样能理清楚报错的来龙去脉，有助于大家针对性的参考)，我按照之前的安装步骤安装好这个es集群后，然后访问了下es集群中各节点的9200端口，显示情况如下：

我本以为es服务这样就是启动成功了，可是之后发现这个仅仅能证明节点启动elasticsearch服务暂时成功了(意思是9200读那口已经被elasticsearch服务占用，但是启动日志可能报错)，待按照以上方式启动各节点的elasticsearch服务后我查看了下es集群中各节点的信息：

这里报了个错误就是master_not_discovered_exception的错误，这个错误就是es集群中master节点没有发现的异常，注意curl -XGET 'http://localhost:9200/_cluster/health?pretty=true'命令返回的es节点状态都是健康的才能说明es集群部署成功，而不是浏览器访问ip地址+9200端口，因为浏览器访问各节点的9200端口成功返回信息的话只能说明各节点的es(elasticsearch)服务启动成功，而不能说明es集群部署成功(因为es集群中所有节点要互相发现，加入集群，es集群才算搭建成功)。

我看了下某个节点上的elasticsearch的启动信息,这样看来elasticsearch的服务确实是启动起来了，这也是上面我访问9200端口能成功访问到cluster相关信息的原因。

但是过了会我的日志信息就报错了，报错如下：
报错信息(图片版)：
报错信息(代码版)：

{"type": "server", "timestamp": "2020-08-27T06:30:51,828Z", "level": "WARN", "component": "o.e.c.c.Coordinator", "cluster.name": "es-cluster", "node.name": "node-a", "message": "failed to validate incoming join request from node [{node-c}{YmHns882QzChKkOGKR0Rcw}{hNqhxLpVTkGqxWHtMXXcFQ}{10.24.2.222}{10.24.2.222:9300}{dilm}{ml.machine_memory=8127139840, ml.max_open_jobs=20, xpack.installed=true}]", "cluster.uuid": "qdaqityTTEKuXwA4cRCclw", "node.id": "FR7TLa4TRbePpKFrF4FVtg" ,
"stacktrace": ["org.elasticsearch.transport.RemoteTransportException: [node-c][172.17.0.2:9300][internal:cluster/coordination/join/validate]",
"Caused by: org.elasticsearch.cluster.coordination.CoordinationStateRejectedException: join validation on cluster state with a different cluster uuid qdaqityTTEKuXwA4cRCclw than local cluster uuid cWcEtWIISVuWM700WsmBZQ, rejecting",
"at org.elasticsearch.cluster.coordination.JoinHelper.lambda$new$4(JoinHelper.java:148) ~[elasticsearch-7.5.0.jar:7.5.0]",
"at org.elasticsearch.xpack.security.transport.SecurityServerTransportInterceptor$ProfileSecuredRequestHandler$1.doRun(SecurityServerTransportInterceptor.java:257) ~[?:?]",
"at org.elasticsearch.common.util.concurrent.AbstractRunnable.run(AbstractRunnable.java:37) ~[elasticsearch-7.5.0.jar:7.5.0]",
"at org.elasticsearch.xpack.security.transport.SecurityServerTransportInterceptor$ProfileSecuredRequestHandler.messageReceived(SecurityServerTransportInterceptor.java:315) ~[?:?]",
"at org.elasticsearch.transport.RequestHandlerRegistry.processMessageReceived(RequestHandlerRegistry.java:63) ~[elasticsearch-7.5.0.jar:7.5.0]",
"at org.elasticsearch.transport.InboundHandler$RequestHandler.doRun(InboundHandler.java:264) ~[elasticsearch-7.5.0.jar:7.5.0]",
"at org.elasticsearch.common.util.concurrent.ThreadContext$ContextPreservingAbstractRunnable.doRun(ThreadContext.java:773) ~[elasticsearch-7.5.0.jar:7.5.0]",
"at org.elasticsearch.common.util.concurrent.AbstractRunnable.run(AbstractRunnable.java:37) ~[elasticsearch-7.5.0.jar:7.5.0]",
"at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?]",
"at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?]",
"at java.lang.Thread.run(Thread.java:830) [?:?]"] }

为方便大家在浏览器中能够尽快找到此类问题的解决方案，再次放上报错信息，报错信息(文字版):

{“type”: “server”, “timestamp”: “2020-08-27T06:30:51,828Z”, “level”: “WARN”, “component”: “o.e.c.c.Coordinator”, “cluster.name”: “es-cluster”, “node.name”: “node-a”, “message”: “failed to validate incoming join request from node [{node-c}{YmHns882QzChKkOGKR0Rcw}{hNqhxLpVTkGqxWHtMXXcFQ}{10.24.2.222}{10.24.2.222:9300}{dilm}{ml.machine_memory=8127139840, ml.max_open_jobs=20, xpack.installed=true}]”, “cluster.uuid”: “qdaqityTTEKuXwA4cRCclw”, “node.id”: “FR7TLa4TRbePpKFrF4FVtg” ,
“stacktrace”: [“org.elasticsearch.transport.RemoteTransportException: [node-c][172.17.0.2:9300][internal:cluster/coordination/join/validate]”,
“Caused by: org.elasticsearch.cluster.coordination.CoordinationStateRejectedException: join validation on cluster state with a different cluster uuid qdaqityTTEKuXwA4cRCclw than local cluster uuid cWcEtWIISVuWM700WsmBZQ, rejecting”,
“at org.elasticsearch.cluster.coordination.JoinHelper.lambda$new4(JoinHelper.java:148)[elasticsearch−7.5.0.jar:7.5.0]","atorg.elasticsearch.xpack.security.transport.SecurityServerTransportInterceptor4(JoinHelper.java:148) ~[elasticsearch-7.5.0.jar:7.5.0]", "at org.elasticsearch.xpack.security.transport.SecurityServerTransportInterceptor4(JoinHelper.java:148) [elasticsearch−7.5.0.jar:7.5.0]","atorg.elasticsearch.xpack.security.transport.SecurityServerTransportInterceptorProfileSecuredRequestHandler1.doRun(SecurityServerTransportInterceptor.java:257)[?:?]","atorg.elasticsearch.common.util.concurrent.AbstractRunnable.run(AbstractRunnable.java:37)[elasticsearch−7.5.0.jar:7.5.0]","atorg.elasticsearch.xpack.security.transport.SecurityServerTransportInterceptor1.doRun(SecurityServerTransportInterceptor.java:257) ~[?:?]", "at org.elasticsearch.common.util.concurrent.AbstractRunnable.run(AbstractRunnable.java:37) ~[elasticsearch-7.5.0.jar:7.5.0]", "at org.elasticsearch.xpack.security.transport.SecurityServerTransportInterceptor1.doRun(SecurityServerTransportInterceptor.java:257) [?:?]","atorg.elasticsearch.common.util.concurrent.AbstractRunnable.run(AbstractRunnable.java:37) [elasticsearch−7.5.0.jar:7.5.0]","atorg.elasticsearch.xpack.security.transport.SecurityServerTransportInterceptorProfileSecuredRequestHandler.messageReceived(SecurityServerTransportInterceptor.java:315) ~[?:?]”,
“at org.elasticsearch.transport.RequestHandlerRegistry.processMessageReceived(RequestHandlerRegistry.java:63) ~[elasticsearch-7.5.0.jar:7.5.0]”,
“at org.elasticsearch.transport.InboundHandlerRequestHandler.doRun(InboundHandler.java:264)[elasticsearch−7.5.0.jar:7.5.0]","atorg.elasticsearch.common.util.concurrent.ThreadContextRequestHandler.doRun(InboundHandler.java:264) ~[elasticsearch-7.5.0.jar:7.5.0]", "at org.elasticsearch.common.util.concurrent.ThreadContextRequestHandler.doRun(InboundHandler.java:264) [elasticsearch−7.5.0.jar:7.5.0]","atorg.elasticsearch.common.util.concurrent.ThreadContextContextPreservingAbstractRunnable.doRun(ThreadContext.java:773) ~[elasticsearch-7.5.0.jar:7.5.0]”,
“at org.elasticsearch.common.util.concurrent.AbstractRunnable.run(AbstractRunnable.java:37) ~[elasticsearch-7.5.0.jar:7.5.0]”,
“at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?]”,
“at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?]”,
“at java.lang.Thread.run(Thread.java:830) [?:?]”] }

我看了下，所有的节点都报这个错误信息，而且是一直报这个错误，查看错误日志的话简直能瞬间刷屏，其实之前我也是遇到过这种情况，之前的解决
方案是将k8s集群中所有节点上的elasticsearch服务重启。从报错信息可以看出，节点报错的主要原因就是“failed to validate incoming join request”——节点加入集群的加入请求信息未能通过验证，而这个的原因正是“join validation on cluster state with a different cluster uu id qdaqityTTEKuXwA4cRCclw than local cluster uuid cWcEtWIISVuWM700WsmBZQ, rejecting"——集群的uuid不一致，这个问题我在网上找了很多资料，基本没怎么方法解决我的这个问题，但网上某些博客提出了这可能是"elasticsearch卸载不彻底的残留"问题。这样一说，我貌似就是遇到了这个问题，但是网上的解决方案没有作用，最后我摸索着解决了这个问题。首先因为之前k8s集群被我不小心删除了(在linux服务器上操作的时候，一定要慎用rm -rf命令)，但是数据磁盘的数据还是存在的(之前k8s集群被删除以后，linux服务器重装了系统，但是没有格式化数据磁盘)，所以我之前elasticsearch的相关文件还是存储在的(而我启动es的命令还是用到了之前的es文件的相关存放目录)，所以我觉得这个可能“配置文件残留或冲突"就是报错的原因。我当时启动elasticsearch服务的命令是:

docker run -e ES_JAVA_OPTS="-Xms512m -Xmx512m" -d \
-p 9200:9200 -p 9300:9300 \
-v /data/es/config/es.yml:/data/share/elasticsearch/config/elasticsearch.yml \
-v /data/es/data:/data/share/elasticsearch/data \
--name ES elasticsearch:7.5.0

确实，之前的/data/es/config/es.yml和/data/es/data文件没有删除，前者的yml文件没什么问题不可能导致残留，我看了下/data/es/data文件：

我打开看了下logs文件是空的，nodes文件加夹下的子文件非常多,

这个时候我就觉得问题应该是出在了这个/data/es/data/nodes文件夹下，既然是残留问题，那我就把所有内容删除，然后再重新启动es服务吧。将这个文件夹下的下的所有文件删除一下：

cd /data/es/data
rm -rf nodes/*

注意：我建议大家以后删除文件夹的命令还是先进到文件的目录里面然后再删除文件，像我之前本来想删除的是/var/lib/ceph文件，结果删除了/var/lib文件，整个k8s集群全部没有了。有关linux服务器上文件或文件夹的删除我在博客待补充博客链接中有提到，这是一件需要注意的事情。
注意以上的/data/es/data/nodes文件夹的删除，要在es集群的所有节点上执行这个删除操作(rm -rf删除操作须谨慎，对于自己来说真的是很惨痛的教训)，待所有节点上的该文件夹内容删除过后，通过docker run再次启动elasticsearch容器进而启动elasticsearch服务，然后es节点上的日志信息是这样的：

错误终于消失了,此时通过curl -XGET 'http://localhost:9200/_cluster/health?pretty=true'命令再次查看es集群的节点信息，是这样的：

3个节点，并且名称为es-cluster的es(elasticsearch)状态是green(健康状态)，至此问题解决。

说明：如果elasticserach服务是和kiabna服务组合使用的，并且启动kibana服务报错——"Unable to connect to Elasticsearch. Error: Request Timeout after 3000ms"这多半是elasticsearch集群出现了问题，使用curl -XGET 'http://localhost:9200/_cluster/health?pretty=true'查看es集群的相关健康状态，然后根据es节点的报错信息针对性的解决问题即可。

es集群节点加入失败join validation on cluster state with a different cluster uuid...than local cluster uuid..相关推荐

【ES实战】ES集群节点迁移与缩容补充说明
[ES实战]ES集群节点迁移与缩容补充说明 [ES实战]ES集群节点迁移与缩容文章目录 [ES实战]ES集群节点迁移与缩容补充说明 1.集群的现状分析和集群的规划 2.集群健康关注点,变化关注点 3 ...
es集群节点数和分片数关系_ES数据插入和查询流程是怎么样的？
ES集群的状态有哪些,为什么主分片数目是固定的,副本分片却能动态调节,快看看这些关于ES的问题你都知道吗? 1. ES集群的状态 green 最健康的状态,说明所有的分片包括备份都可用 yellow ...
es集群节点数和分片数关系_ElasticSeaerch（弹性搜索数据库）中集群、节点、副本和分片的区别...
简单总结下: 1.集群cluster: 集群顾名思义就是多个相同集群名称的es节点组合在一起.相当于一个集群就是一个班级,班级下面的学生就是节点. 如果只有一个节点在运行就称为单节点. 2.节点nod ...
Elasticsearch-Jest 配置ES集群源码解读
文章目录 Jest Github地址搭建源码环境 Jest配置ES集群 Jest 配置ES集群,确保应用高可用的原理探究初始化 JestClient NodeChecker 源码分析发起请求的过 ...
教你在Kubernetes中快速部署ES集群
摘要:ES集群是进行大数据存储和分析,快速检索的利器,本文简述了ES的集群架构,并提供了在Kubernetes中快速部署ES集群的样例:对ES集群的监控运维工具进行了介绍,并提供了部分问题定位经验,最 ...
Elasticsearch——Windows下ES集群部署 Linux下ES单节点、集群部署
1.开篇在之前的两篇文章中,说白了就是在windows下部署的ES单节点的环境. 这篇文章主要是说一下windows下部署ES集群.Linux下单节点部署. 单台 Elasticsearch 服务器 ...
白话Elasticsearch65-最少master候选节点以及ES集群脑裂问题
文章目录概述脑裂的成因分析重要参数:discovery.zen.minimum_master_nodes 举例说明 3个节点,discovery.zen.minimum_master_nodes ...
ES集群新增节点无法加入集群 timed out while waiting for initial discovery state - timeout: 30s
ES : 7.5.0 ES集群新增节点无法加入集群 timed out while waiting for initial discovery state - timeout: 30s ES集群需 ...
Elasticsearch 节点磁盘使用率过高，导致ES集群索引无副本
1.概述转载:https://www.cnblogs.com/operationhome/p/12150530.html 2.问题最近在查看线上的 es,发现最近2天的索引没有副本,集群的状态也是 ...

es集群节点加入失败join validation on cluster state with a different cluster uuid...than local cluster uuid..

es集群节点加入失败join validation on cluster state with a different cluster uuid...than local cluster uuid..相关推荐

最新文章

热门文章