Elasticsearch：使用Shrink API收缩索引后，原索引能否安全删除？

首先给你吃个定心丸：一旦Shrink操作完全成功完成，新的100分片索引是完全独立的，不依赖原500分片的索引，你可以安全删除原索引。

为什么新索引看起来没占用新磁盘空间？ #

这是Shrink API的正常优化行为：如果你的文件系统支持硬链接（比如常见的ext4、XFS），Elasticsearch会用硬链接来创建新索引的底层数据文件，而不是直接复制整个文件。硬链接的特点是多个文件共享同一个磁盘块，所以在你删除原索引之前，新索引不会额外占用磁盘空间——这也是Shrink操作能高效完成的核心原因之一。

当你删除原索引后，新索引的硬链接会自动转为独立的普通文件，此时磁盘空间占用会和原索引的实际数据量（经过分片合并后可能略小）一致，这是正常现象，完全不用担心数据丢失。

安全删除原索引的步骤建议 #

1. 确认Shrink操作彻底完成
   用这个命令查看新索引的状态：

   GET /_cat/indices/<你的新索引名>?v
   

   确保索引状态是green，并且docs.count数值和原索引完全一致，说明数据已经完整迁移到新索引。

2. 验证新索引的数据完整性
   可以随机查询一些关键文档，或者用count API对比两者的文档数：

   GET /<原索引名>/_count
   GET /<新索引名>/_count
   

   两个请求返回的count值必须完全相同，才能确认数据没有遗漏。

3. （可选）解除新索引的只读限制
   Shrink过程中，新索引会被自动设为只读状态。如果后续需要往新索引写入数据，执行以下命令解除限制：

   PUT /<新索引名>/_settings
   {
     "index.blocks.write": false
   }
   

4. 删除原索引
   确认以上步骤都没问题后，就可以放心删除原索引了：

   DELETE /<原索引名>
   

额外提醒 #

如果你的文件系统不支持硬链接，Shrink操作会直接复制数据文件，这时候新索引一开始就会占用对应的磁盘空间，但不管哪种情况，新索引都是完全独立的，原索引删除后不会影响新索引的正常使用。

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