Elasticsearch：重建索引后索引体积翻倍问题排查

附分片信息：

• 截图1：旧索引分片信息，总存储约3.7GB，主副分片数量明确，各分片存储占用均衡；
• 截图2：新索引分片信息，主副分片数量与旧索引一致，总存储约5.2GB，部分分片占用高于旧索引对应分片

以下是可能导致新索引体积偏大的原因：

• 段合并的临时占用与策略差异：重建索引时，Elasticsearch会生成大量临时段文件，后台自动合并需要时间，你观察到的7GB就是合并未完成时的总占用。5.2GB是合并后的结果，但如果新索引的段合并策略（比如merge.policy.max_merged_segment）比旧索引宽松，合并后的段冗余更多，或者还有未完全清理的临时文件，都会让体积比旧索引大。

• 新旧索引配置不一致：检查新索引的分片、副本数、字段映射、分词器、存储设置是否和旧索引完全一致。比如新索引开启了更多字段的store: true、新增了doc_values/fielddata，或者副本同步过程中临时叠加数据，都会增加存储占用；就算副本数和旧索引相同，重建时先写主分片再同步副本的过程中，主副分片的临时数据叠加也会导致体积飙升。

• 备份包含冗余数据：旧索引长期运行中，段合并已经清理了标记为删除的软删除文档，但备份文件可能还保留着这些数据。重建新索引时会把备份里的所有文档（包括这些待清理的冗余数据）先写入，后续才会在段合并中处理，导致初期体积暴增，就算合并完成，也可能残留部分冗余数据，让体积比旧索引大。

• 压缩策略不同：旧索引可能配置了高压缩比的存储参数（比如index.codec: best_compression），而新索引使用默认压缩策略（default），默认压缩比更低，自然会导致存储体积更大。可以通过对比新旧索引的index.codec配置确认这一点。

• 分片未达最优状态：新索引刚完成重建，分片的段分布可能不均衡，存在不少小段，就算经过自动合并，也没达到旧索引长期运行后的最优段状态。如果新索引是只读状态，可以手动执行_forcemerge操作强制合并段，进一步缩小体积。

内容的提问来源于stack exchange，提问作者sheharbano