处理elastic中参与分片（下）

脚本

循环删除
#!/bin/bash
while read line
do
   curl -H "Content-Type: application/json" --user elastic:123456 -XDELETE 172.16.5.35:9200/${line}
done < 索引名称文件

修改副本数

集群中节点数量>=集群中所有索引的最大副本数量 +１，N> = R + 1

其中： N——集群中节点的数目； R——集群中所有索引的最大副本数目。

知识点：当节点加入和离开集群时，主节点会自动重新分配分片，以确保分片的多个副本不会分配给同一个节点。换句话说，主节点不会将主分片分配给与其副本相同的节点，也不会将同一分片的两个副本分配给同一个节点。 如果没有足够的节点相应地分配分片，则分片可能会处于未分配状态。 由于我的集群就一个节点，即Ｎ＝１；所以Ｒ＝０，才能满足公式。

问题就转嫁为： １）添加节点处理，即Ｎ增大； ２）删除副本分片，即R置为0。

R置为0的方式，可以通过如下命令行实现：

root@tyg:/# curl -XPUT "http://localhost:9200/_settings" -d' {  "number_of_replicas" : 0 } '
{"acknowledged":true}

allocate重新分配分片

如果方案二仍然未解决，可以考虑重新分配分片。

可能的原因： 1）节点在重新启动时可能遇到问题。正常情况下，当一个节点恢复与群集的连接时，它会将有关其分片的信息转发给主节点，然后主节点将这分片从“未分配”转换为“已分配/已启动”。

2）当由于某种原因（例如节点的存储已被损坏）导致该进程失败时，分片可能保持未分配状态。

在这种情况下，您必须决定如何继续：尝试让原始节点恢复并重新加入集群（并且不要强制分配主分片）；

或者强制使用Reroute API分配分片并重新索引缺少的数据原始数据源或备份。 如果您决定分配未分配的主分片，请确保将“allow_primary”：“true”标志添加到请求中。

ES5.X使用脚本如下：

allocate重新分配分片
如果方案二仍然未解决，可以考虑重新分配分片。

可能的原因：
1）节点在重新启动时可能遇到问题。正常情况下，当一个节点恢复与群集的连接时，它会将有关其分片的信息转发给主节点，然后主节点将这分片从“未分配”转换为“已分配/已启动”。

2）当由于某种原因（例如节点的存储已被损坏）导致该进程失败时，分片可能保持未分配状态。

在这种情况下，您必须决定如何继续：尝试让原始节点恢复并重新加入集群（并且不要强制分配主分片）；

或者强制使用Reroute API分配分片并重新索引缺少的数据原始数据源或备份。
如果您决定分配未分配的主分片，请确保将“allow_primary”：“true”标志添加到请求中。

ES5.X使用脚本如下：

ES2.X及早期版本，将 allocate_replica改为 allocate，其他不变。

脚本解读： 步骤1：定位 UNASSIGNED 的节点和分片 curl -s 'localhost:9200/_cat/shards' | fgrep UNASSIGNED

步骤2：通过 allocate_replica 将 UNASSIGNED的分片重新分配。

四.核心知识点

1）路由 原理很简单，把每个用户的数据都索引到一个独立分片中，在查询时只查询那个用户的分片。这时就需要使用路由。 使用路由优势：路由是优化集群的一个很强大的机制。 它能让我们根据应用程序的逻辑来部署文档, 从而可以用更少的资源构建更快速的查询。

2）在索引过程中使用路由 我们可以通过路由来控制 ElasticSearch 将文档发送到哪个分片。 路由参数值无关紧要，可以取任何值。重要的是在将不同文档放到同一个分片上时, 需要使用相同的值。

3）指定路由查询 路由允许用户构建更有效率的查询，当我们只需要从索引的一个特定子集中获取数据时, 为什么非要把查询发送到所有的节点呢?

指定路由查询举例: curl -XGET 'localhost:9200/documents/_search?pretty&q=*:*&routing=A'

4）集群再路由reroute reroute命令允许显式地执行包含特定命令的集群重新路由分配。

例如，分片可以从一个节点移动到另一个节点，可以取消分配，或者可以在特定节点上显式分配未分配的分片。

5）allocate分配原理 分配unassigned的分片到一个节点。将未分配的分片分配给节点。接受索引和分片的索引名称和分片号，以及将分片分配给它的节点。

它还接受allow_primary标志来明确指定允许显式分配主分片（可能导致数据丢失）。

五.查看原因

原因肯定是有很多啊，但是要看具体每一次是什么原因引起的，对照表格排查未免不太高效，怎么办？

es 早已帮你想好对策，使用​ Cluster Allocation Explain API，会返回集群为什么不分配分片的详细原因，你对照返回的结果，就可以进行有针对性的解决了。

实验一把：

GET /_cluster/allocation/explain
{
  "index": "test",
  "shard": 0,
  "primary": false,
  "current_state": "unassigned",
  "unassigned_info": {
    "reason": "CLUSTER_RECOVERED",
    "at": "2018-05-04T14:54:40.950Z",
    "last_allocation_status": "no_attempt"
  },
  "can_allocate": "no",
  "allocate_explanation": "cannot allocate because allocation is not permitted to any of the nodes",
  "node_allocation_decisions": [
    {
      "node_id": "ikKuXkFvRc-qFCqG99smGg",
      "node_name": "test",
      "transport_address": "127.0.0.1:9300",
      "node_decision": "no",
      "deciders": [
        {
          "decider": "same_shard",
          "decision": "NO",
          "explanation": "the shard cannot be allocated to the same node on which a copy of the shard already exists [[test][0], node[ikKuXkFvRc-qFCqG99smGg], [P], s[STARTED], a[id=bAWZVbRdQXCDfewvAbN85Q]]"
        }
      ]
    }
  ]
}