ElasticSearch7.6.2使用_delete_by_query產生版本沖突（version conflict）問題
環境：ElasticSearch7.6.2
問題產生的原因：
對某個index的數據進行刪除，刪除的數據量在千萬級別。刪除過程中產生版本沖突。
POST /monitor_user_log_info/_delete_by_query
{"query":{"bool":{"filter":[{"range":{"createTime":{"from":"2020-09-01T00:00:00.000Z",
"to":"2020-09-31T23:59:59.000Z","include_lower":true,"include_upper":true,"boost":1.0}}}],"adjust_pure_negative":true,"boost":1.0}},"track_total_hits":2147483647}
原因如下：
在執行_delete_by_query期間，為了刪除匹配到的所有文檔，多個搜索請求是按順序執行的。每次找到一批文檔時，將會執行相應的批處理請求來刪除找到的全部文檔。如果搜索或者批處理請求被拒絕，_delete_by_query根據默認策略對被拒絕的請求進行重試（最多10次）。達到最大重試次數后，會造成_delete_by_query請求中止，並且會在failures字段中響應 所有的故障。已經刪除的仍會執行。換句話說，該過程沒有回滾，只有中斷。
在第一個請求失敗引起中斷，失敗的批處理請求的所有故障信息都會記錄在failures元素中；並返回回去。因此，會有不少失敗的請求。
如果你想計算有多少個版本沖突，而不是中止，可以在URL中設置為conflicts=proceed或者在請求體中設置"conflicts": “proceed”。
第一步解決后出現超時問題，這是因為我們執行刪除后會等待命令結束之后的結果，但是由於刪除的數據量太大，不可能一時半會兒刪除數據，從而出現超時問題。通過查詢資料發現，這個可以通過加一個參數來設置執行命令之后立即返回，不等待刪除的結果。只要設置wait_for_completion=false即可。
返回結果：
{
"task" : "yzkWe25WQr291Fa9k2S0vg:1766403051"
}
執行完之后立馬返回了一個taskid，我們可以通過這個taskid來查看數據的刪除情況。
GET /_tasks/yzkWe25WQr291Fa9k2S0vg:1766403051
不斷執行，你會發現刪除的數據在不斷增加。
取消單個遷移任務
POST _tasks/node_id:task_id/_cancel
取消全部的刪除數據任務
POST _tasks/_cancel?actions=*delete/byquery
# 參數解釋如下:
# wait_for_completion=false : 開啟異步
# scroll_size=2000 : 刪除文檔數
# slices=2 : 線程數量
# conflicts=proceed : 有沖突不中斷繼續執行
POST monitor_user_log_info/_delete_by_query?wait_for_completion=false&conflicts=proceed&scroll_size=10000&slices=10
{"query":{"bool":{"filter":[{"range":{"createTime":{"from":"2020-09-01T00:00:00.000Z",
"to":"2020-09-31T23:59:59.000Z","include_lower":true,"include_upper":true,"boost":1.0}}}],"adjust_pure_negative":true,"boost":1.0}},"track_total_hits":2147483647}