Elasticsearch 5.6升6.8滚动升级会自动清理已删除文档吗？

滚动升级流程对软删文档的实际处理规则 #

• ES的滚动升级本质是逐节点替换二进制版本、重启后重新加入集群的过程，流程本身不会主动触发分片强制合并，也不会物理清除段文件内标记为已删除的软文档。
• 但因为5.6版本基于Lucene 6内核、6.8版本基于Lucene 7内核，两个大版本的段文件格式完全不兼容，无法互相读取。所以当集群内部分节点升级到6.8版本后，剩余未升级的5.6节点上的分片会被判定为无有效副本，需要把所有分片的有效数据重新迁移到已升级的节点上，重建符合Lucene7格式的段文件。
• 这个跨版本的分片恢复过程，会自动在源节点侧过滤所有被标记为删除的文档，只传输有效文档构建新段——也就是说，升级流程本身天然就会丢弃原来的软删文档标记，不会把软删文档当有效数据迁移过去。

软删文档对升级速度的实际影响 #

• 跨版本分片恢复时，源节点需要逐文档遍历段文件、判断文档是否被标记为删除，再把有效文档流传给目标节点。你当前索引的软删文档占比接近40%，确实会让源端多付出40%左右的遍历IO开销，拉长单分片的恢复时间，进而拉长整体升级窗口。
• 但这个影响是遍历判断的开销，不是把软删文档实际传输的开销，整体影响程度远小于全量拷贝所有带软删标记的段文件的场景。

升级前是否需要提前执行reindex迁移？ #

• 绝大多数场景下没必要特意提前做reindex。因为跨版本恢复的过程本身就会自动过滤软删文档，最终升级完成后集群的分片状态，和你手动reindex到全新索引、清除软删的效果完全等价，额外reindex只会平白增加一次全量数据写入的开销。
• 如果你的升级窗口非常紧张，且节点采用机械硬盘存储，源端遍历软删文档的IO开销可能拖慢恢复速度甚至触发超时，可以选择成本更低的替代方案：在升级前的业务低峰期执行软删清理命令：
  POST /你的目标索引名/_forcemerge?only_expunge_deletes=true
  这个命令会直接将段内的软删文档物理清除，清理完成后所有文档都是有效数据，后续走滚动升级流程时，源端不需要额外做软删判断，分片恢复速度会明显提升，且不需要重建整个索引的元数据、映射、别名配置，比全量reindex的操作成本低很多。

常见误区澄清 #

不存在“升级流程把软删文档完整迁移到新版本集群”的情况，跨大版本的Lucene格式不兼容，决定了所有数据迁移都是基于有效文档重建的逻辑，升级完成后不需要额外再做一次软删清理操作。

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