elasticsearch系列六：索引重建

概述

我们再起初创建索引的时候由于数据量、业务增长量都并不大，常常不需要搞那么多分片或者说某些字段的类型随着业务的变化，已经不太满足未来需求了，再或者由于集群上面索引分布不均匀导致节点直接容量差异较大等等这些情况，此时我们就需要重建索引。

案例

信步云生产环境es集群由于2022年2月刚上线，诸多服务与下半年才逐渐接入导致不同月份的索引之间数据差异较大，导致节点之间容量差了10%以上。

此时有人就有疑问了，为什么会这样呢？索引都是按照同一个模板创建的，大家的分片都是一样的，并且es集群各个节点之间的shard也是比较均衡的。

问题就在这里，es是按照shard进行重平衡的，即便都是40个shard，但是由于每个shard之间的数据量不一致这样就导致了节点之间磁盘利用率的差距。

我们就在es扩容申请时间窗口内顺便把这个问题修复了，怎么搞呢，这时候就需要重建索引了，因为索引的shard是不能动态调整的，你可以调整副本replica 数量，就好比数据库分库分表以后如果按照hash这种方式作为分片算法的话是不能动态扩容的。

es官方给我们提供了reindex api，它可以将一个索引复制到一个新的索引上，其底层采用的scroll api 其用法如下：

复制代码

POST /_reindex{  "source": {    "index": ["log-2022-*"]  },  "dest": {    "index": "log-2022-new"  }}

可以通过通配符的方式将多个索引复制到一个新的索引上，那么对于数据量较小的索引这样是没问题的。但是一旦索引数据量很大并且本身es又是低配版本的，此时就需要对reindex调优了，否则你就开始了漫长的等待过程。

我们可以从这几个维度来调整：

第一 reindex既然是底层依赖scroll api 那么一定是有默认的批量值，通过官方介绍我们知道该值是1000，可以根据实际集群配置将此值调大。

第二借助scroll的 sliced来提升性能，你可以理解它是多线程执行或多进程执行。sliced 可以手工配置也可以配置成auto，该值最好等于你索引的分片数，这样几个分片并行执行效率得到成倍提升。

复制代码

POST /_reindex?slices=5&refresh{  "source": {    "index": ["log-2022-*"],    "size":6000  },  "dest": {    "index": "log-2022-new"  }}

第三将新的索引副本设置为0 等待重建完毕以后再调整副本数量，调大refresh_interval刷新时间，es写入数据是现写jvm内存的默认1秒flush一次

重建完以后我们服务还是读取的旧索引啊，不能再调整程序去吧，此时索引名字变了怎么办呢？我们可以通过别名的方式，将新的索引增加多个别名，该别名可设置成之前的旧索引名字（当然此时旧索引已经删除）默认别名只有读取权限，我们需要通过is_write_index参数设置写入权限。

复制代码

POST /_aliases{  "actions": [    {      "add": {        "index": "test_index",        "alias": "my_alias",        "is_write_index":true      }    }  ]

此时服务就可以平滑迁到了新的索引上了，集群之间的节点使用率也接近一致了。