一、前言

在ES-head删除索引的时候常常出现很多问题，当大数据量删除的时候往往不是超时就是报错409冲突，具体内容是version conflict,required seqNo [],primary term [],but no document was found

出现这个的原因主要是因为使用随机_id，es内的乐观锁造成的删除不够完全，导致版本号冲突。乐观锁相关的说明可以参见博客Elasticsearch-并发冲突处理机制

网上有说要改用自定义的_id，但是其实不需要，当数据量大的时候也很难操作，找到了一种解决方案，就是在删除操作的时候加上一个字段?wait_for_completion=false

可以参见博客ElasticSearch6：解决大批量删除数据，导致超时的问题

以下做法主要实现的就是：

①掩耳盗铃——超时与我无关别告诉我

②默默无闻——后台不停运行删除操作，不用我们手动

二、具体操作

1.添加字段?wait_for_completion=false

这个时候的返回就变成了一个工作编号，接着在head索引页面观察数据量，发现数据量在减少，说明删除操作正在运行，但是由于不用返回信息，所以无法判断运行状况

2.重复提交请求

如果是在head页面操作，就可以把工作请求的频率设置为2s/次或者其他，会发现task编号不断刷新，相当于不停地运行新的删除请求，就算冲突多，也挡不住不停地删

设置2s一次是因为一秒的时候似乎有点太频繁，反而会卡住，发现task内容一直没有变动，包括head数据量也没有减少，可能2s会更合适一些

三、查看任务状态

要查看任务状态，就在网页端输入http://localhost:port/_task/task编码，可以发现目前还是一个正在运行的状态，若运行结束，completed将会显示true

其他

这可能不是最好的方法，运行起来依然效率很低，数据量减得很慢，大约5s钟删除2W的数据，但是比自己手动看着总是超时要舒服得多。我目前还没有找到更好的方式，有建议或经验的欢迎给我私信或者评论里探讨~

另外还有博客说可以用python编程实现，但是似乎有些复杂就没有研究

针对冲突问题，还有一种方式是说进行强制执行删除，可以用?conflicts=proceed，与前面的同理，加在_delete_by_query后面，但是我用这个方法似乎一直超时，也不知道和直接删除有什么区别，就没有使用了，可参见探究 | Elasticsearch如何物理删除给定期限的历史数据？

 

 

参考链接：

ES解决版本冲突问题(version conflict)

409 Conflict

Elasticsearch-并发冲突处理机制

Elasticsearch删除数据操作，你必须知道的一些坑

ElasticSearch6：解决大批量删除数据，导致超时的问题

Elasticsearch7.3.2 单点备份和还原(crul、es-head两种操作方式)

探究 | Elasticsearch如何物理删除给定期限的历史数据？