开发者社区> 桃子红了呐> 正文
阿里云
为了无法计算的价值
打开APP
阿里云APP内打开

Recovering unassigned shards on elasticsearch 2.x——副本shard可以设置replica为0在设置回来

简介:
+关注继续查看

Recovering unassigned shards on elasticsearch 2.x

摘自:https://z0z0.me/recovering-unassigned-shards-on-elasticsearch/

I got accross the problem when decided to add a node to the elasticsearch cluster and that node was not able to replicate the indexes of the cluster. This issue is usually happens when there is not enough disk space available, or not available master or different elasticsearch version. While my servers had more than enough disk space and also the master was available with the help of the elasticsearch discuss I found out that the new node was having a different version than old nodes. Basically while installing on Debian jessie I just run apt-get install elasticsearch which ended up installing the latest available version. To install a specific version of the elasticsearch you prety much need to add ={version}.

#apt-get install elasticsearch={version}

Now that I have identified the reasons for unallocated shards and successfully downgraded the elasticsearch to the required version by running the command above after starting the node the cluster was still in red state with unassigned shards all over the place:

#curl http://localhost:9200/_cluster/health?pretty
 {
   "cluster_name" : "z0z0",
   "status" : "red",
   "timed_out" : false,
   "number_of_nodes" : 3,
   "number_of_data_nodes" : 3,
   "active_primary_shards" : 6,
   "active_shards" : 12,
   "relocating_shards" : 0,
   "initializing_shards" : 0,
   "unassigned_shards" : 8,
   "delayed_unassigned_shards" : 0,
   "number_of_pending_tasks" : 0,
   "number_of_in_flight_fetch" : 0,
   "task_max_waiting_in_queue_millis" : 0,
   "active_shards_percent_as_number" : 60.0
 }

#curl http://localhost:9200/_cat/shards
site-id      4 p UNASSIGNED                                                 
site-id      4 r UNASSIGNED                                                 
site-id      1 p UNASSIGNED                                                 
site-id      1 r UNASSIGNED                                                 
site-id      3 p STARTED    0 159b 10.0.0.6 node-2 
site-id      3 r STARTED    0 159b 10.0.0.7 node-3 
site-id      2 r STARTED    0 159b 10.0.0.6 node-2 
site-id      2 p STARTED    0 159b 10.0.0.7 node-3 
site-id      0 r STARTED    0 159b 10.0.0.6 node-2 
site-id      0 p STARTED    0 159b 10.0.0.7 node-3 
subscription 4 p UNASSIGNED                                                 
subscription 4 r UNASSIGNED                                                 
subscription 1 p UNASSIGNED                                                 
subscription 1 r UNASSIGNED                                                 
subscription 3 p STARTED    0 159b 10.0.0.6 node-2 
subscription 3 r STARTED    0 159b 10.0.0.7 node-3 
subscription 2 r STARTED    0 159b 10.0.0.6 node-2 
subscription 2 p STARTED    0 159b 10.0.0.7 node-3 
subscription 0 p STARTED    0 159b 10.0.0.6 node-2 
subscription 0 r STARTED    0 159b 10.0.0.7 node-3

At this point I was pretty desperate and whatever I tried it either did not do anything or ended up in all kind of failures. So I set the number_of_replicas to 0 by running the following query:

#curl -XPUT http://localhost:9200/_settings?pretty -d '
{
  "index" : {
    "number_of_replicas' : 0
  }
}'

and started to stop the nodes one by one until I was having only one live node. 
At this point I decided to start trying to reroute the unassigned shards and if it won't work I would just start over my cluster. So I did run the following:

#curl -XPOST -d '
{
  "commands" : [ {
    "allocate" : {
      "index" : "site-id",
      "shard" : 1,
      "node" : "node-3",
      "allow_primary" : true
    }
  } ]
}' http://localhost:9200/_cluster/reroute?pretty

I've seen that the rerouted shard became initialized then running so I did the same command on the rest of unassigned shards. 
Running curl http://localhost:9200/_cluster/health?pretty confirmed that I am on the good track to fix the cluster.

#curl http://localhost:9200/_cluster/health?pretty
{
  "cluster_name" : "z0z0",
  "status" : "green",
  "timed_out" : false,
  "number_of_nodes" : 1,
  "number_of_data_nodes" : 1,
  "active_primary_shards" : 10,
  "active_shards" : 20,
  "relocating_shards" : 0,
  "initializing_shards" : 0,
  "unassigned_shards" : 0,
  "delayed_unassigned_shards" : 0,
  "number_of_pending_tasks" : 0,
  "number_of_in_flight_fetch" : 0,
  "task_max_waiting_in_queue_millis" : 0,
  "active_shards_percent_as_number" : 100.0
}

So the cluster was green again but was running out of one node. So it was time to bring up the other nodes one by one. When all the nodes were up I set the number_of_replicas to 1 by running the following:

#curl -XPUT http://localhost:9200/_settings -d '
{
  "index" : {
    "number_of_replicas" : 1
  }
}'

So my elasticsearch cluster is back on running 3 nodes and still in green state. After alot of googling and wasted time I decided to write this article so that if anyone would come accross this issue would have a working example of how to fix it.













本文转自张昺华-sky博客园博客,原文链接:http://www.cnblogs.com/bonelee/p/7459391.html,如需转载请自行联系原作者


版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
【Mongodb】 Replica set 的选举策略之一
首先介绍一下在replica set里分为三种节点类型: 1 primary   负责client的读写。 2 secondary 作为热备节点,应用Primary的oplog读取的操作日志,和primary保持一致,不提供读写操作!   secondary有两...
1258 0
mongodb分片集群(sharding with replica set)配置
一共有4台机器,各自挂接一个存储,希望实现: 尽量节约存储 高可用性 存储大量数据 配置方案: 每一台机器做一个分片的主数据库 每一台机器做一个分片的后备数据库 每一台机器做一个分片的仲裁服务 两个两个一组交叉作对方的后备 有三台机器开配置服务 有一台机器开路由服务(生产环境可以在每一台Windows App服务器上开路由服务,App服务器集群做负载均衡) 这样的话,任何一台服务器完全离线(或者交叉的两台服务器离线),都能保证整个系统正常运行。
642 0
MongoDB系列-在复制集(replication)以及分片(Shard)中创建索引
在使用MongoDB时,在创建索引会涉及到在复制集(replication)以及分片(Shard)中创建,为了最大限度地减少构建索引的影响,在副本和分片中创建索引,使用滚动索引构建过程。
0 0
分片集群Mongos到Shard请求管理
MongoDB Sharded Cluster 原理 如果你还不了解 MongoDB Sharded cluster,可以先看文档认识一下 中文简介:MongoDB Sharded cluster架构原理 英文汇总:https://docs.mongodb.com/manual/sharding/ Mongos 到 Shard请求管理 Mongos 是 MongoDB 分片集群的访问入口,Mongos 收到 Client 访问请求,会根据从 Config Server 获取的路由表将请求转发到后端对应的 Shard 上。
3858 0
[ElasticSearch2.x]副本分片
1. 副本分片 到目前为止,我们只讨论了主分片,但是我们还有另一个工具:副本分片。 副本分片的主要目的是为了故障转移(failover),如深入集群生命周期所述:如果持有主分片的节点死亡,则将其副本提升为主分片的角色。
732 0
Redis Cluster集群收缩主从节点详细教程
文章目录 Redis Cluster集群收缩主从节点 1.Cluster集群收缩概念 2.将6390主节点从集群中收缩 2.1.计算需要分给每一个节点的槽位数 2.2.分配1365个槽位给192.168.81.210的6380节点 2.3.分配1365个槽位给192.168.81.220的6380节点 2.4.分配1365个槽位给192.168.81.230的6380节点 2.5.查看当前集群槽位分配 3.验证数据迁移过程是否导致数据异常 4.将下线的主节点从集群中删除 4.1.删除节点 4.2.调整主从交叉复制 4.3.当节点存在数据无法删除 5.将下线主机清空集群信息
0 0
高可用mongodb集群(分片+副本):shard2副本重建
高可用mongodb集群(分片+副本):shard2副本重建
0 0
文章
问答
文章排行榜
最热
最新
相关电子书
更多
低代码开发师(初级)实战教程
立即下载
阿里巴巴DevOps 最佳实践手册
立即下载
冬季实战营第三期:MySQL数据库进阶实战
立即下载