避坑！一次ES索引分片扩增实践复盘

背景

上次谈到生产环境中最为便捷的ES分片扩增方案——Split，它适用于仅因为初始分片数设置过少导致的一些性能、磁盘存储问题。

索引拆分（split）操作虽然简单快捷，但是基于少量示例数据的测试还是无法还原事情的全貌。

使用自带的demo数据，仅仅几兆的大小完全看不出什么问题来，因此索引分片的拆分几乎是在瞬间就完成了，来不及观察。今天分享的是对于大索引拆分需要注意的两个注意事项。同时，通过实践证明Split拆分扩大索引分片的效率是极高的，这也是生产环境中分秒必争情况下优先考虑Split方案的另一个关键因素。

问题处理记录

问题现象

用户反馈ES写入特别慢，索引写入延迟达到几百毫秒（正常的几乎是0ms）。

排查定位

我们注意到，在特定的时间段内，Elasticsearch集群承受了极高的查询负载。在平峰时段也有约1000个查询在运行。这些查询主要集中在对大型索引的读取操作上，这很可能导致了磁盘使用率的显著上升。 Elasticsearch集群在高负载时会对磁盘产生大量的读请求，这可能导致磁盘使用率飙升（后台监测发现I/O使用率100%），并可能影响到整体的磁盘性能。 进一步检查发现一些主要业务索引分片过少（10个），单个分片达到229GB，远超分片建议上限50G。 加上其他一些排查分析，最后定位问题为： 超大索引未拆分，分片过少不均衡，难以利用集群的性能，并且存在读写热点问题。

解决方案

由于业务侧短时间不会修改代码进行优化，我能采取的建议措施就是：

1. 数据节点间均衡
2. ES索引分片扩增

因此第一步先对集群实施了ES数据自动均衡的操作，200亿数据量耗时约2小时，节点间存储占比趋于一致。

第二步也就是核心操作，拆分大索引，扩大其分片数，然后业务使用扩大分片数后的新索引（或别名）。具体命令在其他文章已经阐明，不再赘述。

此间遇到两个需要特别注意的点，一定要注意！！

问题复盘

注意事项1

扩建索引的主分片数据很快完成，但是副本分片拷贝十分缓慢。 副本分片拷贝时磁盘占用率和网络占用急速飙升，后台监控甚至超过100%！

• 万兆网络使用达到峰值：

• 磁盘使用率达到100%+:

这会导致部分ES节点开始掉线，掉线的节点上线后又需要大量I/O，进一步加剧了磁盘争抢，导致节点多次掉线的恶性循环，拉低了恢复进度。

注意事项2

这是索引分片扩增过程的一个雷区——数据过度膨胀！

尽管我们的目标是同样的数据扩成更多的分片，理论上数据存储临时需要多一倍，等扩增完成后老索引就可删除释放空间了。

但是经过反复观察几个大索引的拆分过程发现数据量在分片拆分过程膨胀了5倍左右（统计了2个）：

原始索引	新索引大小	膨胀系数
5.5TB	22.6TB	4.11x
1.5TB	7.2TB	4.80x

更多的索引也是类似的表现。但索引大小会在一天之内恢复到初始水平。

以上注意事项在实践中应当加以考虑，以免事倍功半！

结语

与君共赏：

古人学问无遗力，少壮工夫老始成。
纸上得来终觉浅，绝知此事要躬行。

欢迎关注我的公众号[1024点线面]！实践真知，不容错过。

本文由 mdnice 多平台发布