Elasticsearch Shrink缩小分片数

     相信大家都知道 elasticsearch 索引的 shard 数是固定的，设置好了之后不能修改，如果发现 shard 太多或者太少的问题，之前如果要设置 Elasticsearch 的分片数，只能在创建索引的时候设置好，并且数据进来了之后就不能进行修改，如果要修改，只能重建索引。

    现在有了 Shrink 接口，它可将分片数进行收缩成它的因数，如之前你是 15 个分片，你可以收缩成 5 个或者 3 个又或者 1 个，如果是素数例如7个分片，只能缩小为1个。那么我们就可以想象成这样一种场景，在写入压力非常大的收集阶段，设置足够多的索引，充分利用 shard 的并行写能力，索引写完之后收缩成更少的 shard，提高查询性能。

Shrink原理

• 首先，它创建一个新的目标索引，其定义与源索引相同，但主分片数量较少。
• 然后，它将源索引中的段硬链接到目标索引。（如果文件系统不支持硬链接，则会将所有段复制到新索引中，这是一个更耗时的过程。）
• 最后，它恢复了目标索引，好像它是一个刚重新打开的封闭索引。

机器要求

       Shrink主机需要有更大的磁盘和内存，必须能容得下所有数据。

操作步骤

    1、为了缩小索引，必须将原索引标记为只读，并且索引中每个分片的（主要副本或副本）副本必须重定位到同一节点并具有运行状况 green

PUT /source_index/_settings
{
  "settings": {
    "index.routing.allocation.require._name": "node-1",
    "index.blocks.write": true
  }
}

     重新定位源索引可能需要一段时间。可以使用_cat recoveryAPI跟踪进度，或者可以使用cluster healthAPI等待所有分片都已使用wait_for_no_relocating_shards参数重定位。

   2.要收缩 source_index 到一个名为的新索引 target_index

POST /source_index/_shrink/target_index
{
  "settings": {
    "index.number_of_replicas": 1,
    "index.number_of_shards": 1,
    "index.codec": "best_compression"
  },
  "aliases": {
    "search_indices": {}
  }
}

     有人肯定会问慢不慢？非常快！ Shrink 的过程会借助操作系统的 Hardlink 进行索引文件的链接，这个操作是非常快的，毫秒级 Shrink 就可收缩完成，当然 windows 不支持 hard link，需要拷贝文件，可能就会很慢了。

   3.恢复原索引写操作

PUT /source_index/_settings
{
  "settings": {
    "index.blocks.write": false
  }
}