SERVER-17397: Dropping a Database or Collection in a Sharded Cluster may not fully succeed?是 MongoDB 里老大難的問題，庫或集合刪除操作如果沒有完全執行成功，再新建相同名字的集合，可能導致讀到老版本數據的問題。

集合分片原理

MongoDB sharding 分片原理參考?MongoDB Sharded cluster架構原理

總的來說，當用戶對集合執行開啟分片之后，集合分片的元數據會保存在 config server 的 config 集合里

• config.collections?記錄集合分片的元數據，根據哪個 shardKey 分片，集合是否已經被刪除等元數據
• config.chunks，記錄各個 chunk（shardKey的某一段范圍）對應的 shard 信息，用于路由請求
• 各個 shard 里存儲集合實際的數據

刪除分片集合流程

刪除所有 shard 里的對應的數據

刪除 config.chunks 這個集合相關的chunk信息

修改 config.collections，標記集合已經刪除

注：3.2+都是按上述流程操作，刪除 Database 過程類似，還需要再額外操作 config.databases 集合，但本質上存在的問題類似

上述動作需要操作 config server 以及 所有的 shard，如果中間有步驟失敗（一些很老的版本，并不是按照上述步驟執行，而且執行過程中可能沒有嚴格檢查返回的錯誤碼，即使返回成功實際上內部可能執行失敗），最終導致集合的部分數據仍然殘留，沒有完全清理干凈。

如果這個集合名字重新被使用，再次調用 shardCollection 產生新的分片元數據，可能導致

在 shard 上的一些殘留數據可能被讀取到，而這些數據實際上應該被刪除了

mongos 沒有成功更新路由信息，最終可能出現多個 mongos 看到的數據視圖也不一致，有的 mongos 能讀到數據，有的讀不到（通過 `flushRouterConfig 命令可以強制刷新路由信息可解決）

解決方案

MongoDB sharding 刪除集合/數據庫涉及到多個節點進行操作，這些動作無法做到原子性，可能導致一個集合最終處于某種中間狀態；復用該集合可能導致一寫數據一致性問題。

使用 MongoDB 3.2+ 以上版本，大部分case，只要沒有異常，刪除集合動作都能正常完成的，復用集合名字問題一般問題也不大，但無法完全避免問題。

建議 Sharding 環境下，namespace 名字一旦被刪除，不要再次復用

在需要復用 Namespace 的情況下，如果要確保不會有數據問題，每次可以按?drop collection workaround?確保相關數據被正確清理，并且路由信息被更新。

搶阿里云新用戶專屬優惠權益，致電95187-1 ！

原文鏈接
本文為云棲社區原創內容，未經允許不得轉載。

總結

以上是生活随笔為你收集整理的MongoDB Sharding 请勿复用已删除的 namespace的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。