您当前的位置： 首页 > 慢生活 > 程序人生 网站首页程序人生
elasticSearch集群配置分片副本节点解决Unassigned问题
发布时间：2021-09-08 17:43:49编辑：雪饮阅读（）
在https://www.gaojiupan.cn/manshenghuo/chengxurensheng/3934.html一文中我们配置了master与data节点分离的集群。
那么如果这个master与data节点分离的集群中若你没有新增自定义索引而只是默认的那个.geoip_databases则你会发现集群健康状态是绿色的。
但是若你创建了自定义索引并且这个自定义索引中有了文档后就会出现Unassigned提示并且集群健康状态变成黄色yellow状态了。（只建立索引没有建立文档、只建立索引和类型或映射或设置之类的然后没有建立文档这些情况我没有亲测过，我感觉应该也会变成黄色yellow状态）。
出现这种情况是因为没有创建数据副本节点，也可以说是分片副本节点。
这主要取决于你创建索引时候的设置信息中分片副本的数量配置了
像是这样默认分片副本数量是1，有人说如果显式的修改为0就不会出现黄色状态了，当然这种是有丢失数据的风险的，这里我也没有亲测过。
这里主要是以不修改这个副本数量的方式来解决这个问题。
那么就以这个schools的副本数为1为例，那么基于上次我们配置的master与data组成的集群的基础上来实现这个问题的解决。
因为目前集群中只有一个数据节点，那么我们只需要再配置一个数据节点，问题就解决了。
我这里是克隆上次那个win7的虚拟机然后我们只需要将原win7虚拟机中elasticSearch配置文件elasticsearch.yml中discovery.seed_hosts配置修改新增克隆出来的这个新的win7的ip地址，如：
discovery.seed_hosts: ["192.168.43.71", "192.168.43.76","192.168.43.253"]
同时我们将新增克隆出来的这个win7中elasticSearch中配置文件elasticsearch.yml中discovery.seed_hosts配置中也是上面这个相同配置。
接下来新增克隆出来的这个win7中elasticSearch中配置文件elasticsearch.yml中的节点名称修改下，要区别于原win7中那个elasticSearch的节点名称配置，如：
node.name: "node-win7-2"
接下来克隆出来的这个win7中elasticSearch配置文件elasticsearch.yml中配置的数据目录如：
path.data: "C:/software/elasticsearch-7.14.0/myData"
这里这个C:/software/elasticsearch-7.14.0/myData目录要自己进入这个目录并将这个目录里面清空使得这个目录是一个空目录。
那么再接下来就是分别把master、data、data副本（克隆出来的新的win7）这三个elasticSearch实例都启动起来。
那么接下来没有什么问题的话，会看到集群状态再次变成绿色的健康的了，即便是包含你自定义的索引。
需要注意的是上面的克隆出来的win7中C:/software/elasticsearch-7.14.0/myData目录要是不清空，则会出现类似：
[2021-09-08T17:09:31,534][INFO ][o.e.c.c.JoinHelper ] [node-win7-2] failed to join {node-win10}{rdhmaq83THqJKKbufzILPg}{FvuZkJ7MQrKwmPu1xWHEZg}{192.168.43.71}{192.168.43.71:9300}{ilmr}{ml.machine_memory=25602416640, ml.max_open_jobs=512, xpack.installed=true, ml.max_jvm_size=1073741824, transform.node=false} with JoinRequest{sourceNode={node-win7-2}{U5DcuznrSSSIc9JqmWJJPA}{OqDHXl3KSqmPPw7DlB5ZNA}{192.168.43.253}{192.168.43.253:9300}{cdfhilrstw}{ml.machine_memory=4294369280, xpack.installed=true, transform.node=true, ml.max_open_jobs=512, ml.max_jvm_size=1073741824}, minimumTerm=14, optionalJoin=Optional[Join{term=14, lastAcceptedTerm=3, lastAcceptedVersion=68, sourceNode={node-win7-2}{U5DcuznrSSSIc9JqmWJJPA}{OqDHXl3KSqmPPw7DlB5ZNA}{192.168.43.253}{192.168.43.253:9300}{cdfhilrstw}{ml.machine_memory=4294369280, xpack.installed=true, transform.node=true, ml.max_open_jobs=512, ml.max_jvm_size=1073741824}, targetNode={node-win10}{rdhmaq83THqJKKbufzILPg}{FvuZkJ7MQrKwmPu1xWHEZg}{192.168.43.71}{192.168.43.71:9300}{ilmr}{ml.machine_memory=25602416640, ml.max_open_jobs=512, xpack.installed=true, ml.max_jvm_size=1073741824, transform.node=false}}]}
org.elasticsearch.transport.RemoteTransportException: [node-win10][192.168.43.71:9300][internal:cluster/coordination/join]
Caused by: java.lang.IllegalArgumentException: can't add node {node-win7-2}{U5DcuznrSSSIc9JqmWJJPA}{OqDHXl3KSqmPPw7DlB5ZNA}{192.168.43.253}{192.168.43.253:9300}{cdfhilrstw}{ml.machine_memory=4294369280, ml.max_open_jobs=512, xpack.installed=true, ml.max_jvm_size=1073741824, transform.node=true}, found existing node {node-win7}{U5DcuznrSSSIc9JqmWJJPA}{t1xu4DVGTlmFhQq-mnysjw}{192.168.43.76}{192.168.43.76:9300}{cdfhilrstw}{ml.machine_memory=4294369280, ml.max_open_jobs=512, xpack.installed=true, ml.max_jvm_size=1073741824, transform.node=true} with the same id but is a different node instance
at org.elasticsearch.cluster.node.DiscoveryNodes$Builder.add(DiscoveryNodes.java:644) ~[elasticsearch-7.14.0.jar:7.14.0]
at org.elasticsearch.cluster.coordination.JoinTaskExecutor.execute(JoinTaskExecutor.java:148) ~[elasticsearch-7.14.0.jar:7.14.0]
at org.elasticsearch.cluster.coordination.JoinHelper$1.execute(JoinHelper.java:124) ~[elasticsearch-7.14.0.jar:7.14.0]
at org.elasticsearch.cluster.service.MasterService.executeTasks(MasterService.java:691) ~[elasticsearch-7.14.0.jar:7.14.0]
at org.elasticsearch.cluster.service.MasterService.calculateTaskOutputs(MasterService.java:313) ~[elasticsearch-7.14.0.jar:7.14.0]
at org.elasticsearch.cluster.service.MasterService.runTasks(MasterService.java:208) ~[elasticsearch-7.14.0.jar:7.14.0]
at org.elasticsearch.cluster.service.MasterService.access$000(MasterService.java:62) ~[elasticsearch-7.14.0.jar:7.14.0]
at org.elasticsearch.cluster.service.MasterService$Batcher.run(MasterService.java:140) ~[elasticsearch-7.14.0.jar:7.14.0]
at org.elasticsearch.cluster.service.TaskBatcher.runIfNotProcessed(TaskBatcher.java:139) ~[elasticsearch-7.14.0.jar:7.14.0]
at org.elasticsearch.cluster.service.TaskBatcher$BatchedTask.run(TaskBatcher.java:177) ~[elasticsearch-7.14.0.jar:7.14.0]
at org.elasticsearch.common.util.concurrent.ThreadContext$ContextPreservingRunnable.run(ThreadContext.java:673) ~[elasticsearch-7.14.0.jar:7.14.0]
at org.elasticsearch.common.util.concurrent.PrioritizedEsThreadPoolExecutor$TieBreakingPrioritizedRunnable.runAndClean(PrioritizedEsThreadPoolExecutor.java:241) ~[elasticsearch-7.14.0.jar:7.14.0]
at org.elasticsearch.common.util.concurrent.PrioritizedEsThreadPoolExecutor$TieBreakingPrioritizedRunnable.run(PrioritizedEsThreadPoolExecutor.java:204) ~[elasticsearch-7.14.0.jar:7.14.0]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130) ~[?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630) ~[?:?]
at java.lang.Thread.run(Thread.java:831) [?:?]
这样的报错于elasticSearch实例启动过程中。
那么如果清空了克隆出来的win7中C:/software/elasticsearch-7.14.0/myData目录，虽然启动实例过程中也会有错误抛出，但是最后实例还是正常起来了，而不清空的情况下，报出上面这种错误就会一直不停的循环报这个相同的错误。
另外就是，发现这个elasticSearch搭建了副本节点后启动实例好慢啊，运行elasticsearch.bat时候会发现光标一直闪烁，好久才反应。
当时我原本那个win7虽然也慢，但是相比克隆出来的这个win7中就快了不少，不过也大概是因为我原本win7开机早并且启动实例早，而克隆出来的这个win7开机迟并且实例启动的比较迟，具体原因也就不纠结了，意义不大。暂时觉得影响也不算多大。不需要纠结这些啦。除非后面有专门的需要对这个进行优化。废话有点多了，今天就先到这里了。
关键字词：elasticSearch,副本,节点,分片,配置,集群