force merge后（force merge时索引仍有零星读写），未能删除过期的segments，导致索引大小持续增长
索引真实大小：800 GB
当前索引大小：1.2 TB
当前降低索引大小的方式：1.滚动重启es集群；2. reindex
滚动重启后索引大小恢复到800GB（可稳定复现）
随着读写和forcemerge操作后，索引大小会在1.2-1.4T间波动（可稳定复现）
通过api获取索引的segments信息，获取的segments大小相加的大小在800GB左右，但整体索引大小却是1.2-1.4TB，在相应的es节点上进行du统计得出的大小也是1.2-1.4TB
查询segments信息api：
GET /_cat/segments/{target_index}?v&s=docs.deleted:desc,segment
es版本：6.8.4
备注：
每次执行的forcemerge的索引有5个，只有其中最大的这个索引有问题，其他索引没有问题（其他索引大小在100-600GB）
很奇怪，求助！
4 个回复
Charele - Cisco4321
赞同来自:
forceMerge操作里有个only_expunge_deletes参数可以试下看看能不能释放空间。
Charele - Cisco4321
赞同来自:
你说这个"触发写保护“是啥意思？报错？有具体的日志吗？
Ombres
赞同来自:
2. 强制段合并结束以后，老段并不一定会被立刻清除，如果仍有reader在读取老的段，那么这些段不会被删除，常规情况下，如果段没有被使用，那么会在commit()过程后清除老段
3. 强制段合并，一般来说会减少一些存储，常规情况下取决于索引中deleted状态的文档的数量，如果数量很少，那么能节省的空间有限，另外就是取决于index.codec，也就是压缩的算法。
4. 强制段合并，可能产生比较大的段，这些段可能不会参与后续的自动段合并，切记谨慎操作。一般来说只建议对数据变更极少的索引进行此操作。
Charele - Cisco4321
赞同来自:
在索引分别为800g和1.2T的时候，执行下这个命令，
主要看看哪些部分的大小有明显的差异。