發現問題
shard屬于unassign的狀態, 直接的信息可以看到是failed to create shard. failed to obtain in-memory shard.
shard只有在擁有shard的節點關機重啟(與master失去聯系, 即master不知道shard的狀態才會被重新分配).
所以表象問題有兩個:
- shard為什么會重新分配? 如果是節點重啟, 為什么?
- shard為什么不能被創建?
通過查看日志, 得知此節點由于負載過高, full-gc時間過長, 而導致與master的心跳中斷, 但是gc結束后, 又迅速重新加入的集群 , 而節點的此shard上正在被關閉, 且一直沒有成功關閉.
獲取鎖的代碼: org.opensearch.index.IndexService#createShard. 獲取鎖失敗的根因是因為: closing shard 持有著鎖, 且沒有放棄. 導致create在超過約定的重試次數后就不再創建了.
由于沒有開debug日志, 沒有關于為什么close shard的日志.
為什么負載高, 在節點離開集群前, 看到有兩個執行了十幾秒的查詢, 而后在這個shard上還有2m的查詢, 應該是它們導致的負載變高
解決:
/_cluster/reroute?retry_failed=true
不會丟失數據, 觸發重新分配.
或者重啟節點, 就可以釋放掉內存鎖.但是可能部分丟失數據
GET /_cat/indices?v&health=yellow
查看處于亞健康的index
GET _cluster/allocation/explain
查看為什么分配失敗, 原因是什么, 就不用查日志了.
參考:
https://aws.amazon.com/cn/premiumsupport/knowledge-center/opensearch-in-memory-shard-lock/
https://elasticsearch.cn/question/3998
https://github.com/elastic/elasticsearch/issues/23199
