本來之前已經將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$new$4(JoinHelper.java:148)[elasticsearch?7.5.0.jar:7.5.0]","atorg.elasticsearch.xpack.security.transport.SecurityServerTransportInterceptor$ProfileSecuredRequestHandler$1.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.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]","atorg.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) [?:?]”] }

我看了下，所有的節點都報這個錯誤信息，而且是一直報這個錯誤，查看錯誤日志的話簡直能瞬間刷屏，其實之前我也是遇到過這種情況，之前的解決
方案是將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..的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。