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

集合分片原理

MongoDB sharding 分片原理參考?MongoDB Sharded cluster架構(gòu)原理

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

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

刪除分片集合流程

刪除所有 shard 里的對應(yīng)的數(shù)據(jù)

刪除 config.chunks 這個集合相關(guān)的chunk信息

修改 config.collections，標記集合已經(jīng)刪除

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

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

如果這個集合名字重新被使用，再次調(diào)用 shardCollection 產(chǎn)生新的分片元數(shù)據(jù)，可能導(dǎo)致

在 shard 上的一些殘留數(shù)據(jù)可能被讀取到，而這些數(shù)據(jù)實際上應(yīng)該被刪除了

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

解決方案

MongoDB sharding 刪除集合/數(shù)據(jù)庫涉及到多個節(jié)點進行操作，這些動作無法做到原子性，可能導(dǎo)致一個集合最終處于某種中間狀態(tài)；復(fù)用該集合可能導(dǎo)致一寫數(shù)據(jù)一致性問題。

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

建議 Sharding 環(huán)境下，namespace 名字一旦被刪除，不要再次復(fù)用

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

搶阿里云新用戶專屬優(yōu)惠權(quán)益，致電95187-1 ！

原文鏈接
本文為云棲社區(qū)原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。