MongoDB中一個分片的重負載

我的一個分片有問題。出於某種原因，我得到了下一個用法：

15:38:42 上升 4 天，10:28，1 個使用者，平均負載：3.67、3.50、3.56

與此同時，所有其他分片都正常。他們的平均負載約為：

16:49:58 11 天，56 分鐘，1 個使用者，平均負載：0.03、0.03、0.05

我有 3 個配置、2 個查詢和 7 個分片（它們都是主副本集。不要問為什麼）。

我有 2 個數據庫：20Gb 和 30gb。所有伺服器的配置都相同。此外，在每個數據庫中只有 1 個集合。在彩信控制面板中，我看到：

也許這裡有問題？我如何調查這個問題並解決它？

因為我是 MongoDB 新手，所以我使用下一篇文章來配置我的分片：

https://stackoverflow.com/questions/19672302/how-to-programatically-pre-split-a-guid-based-shard-key-with-mongodb

請檢查第一個接受的答案。或者我怎樣才能自己破解我的分片鍵？

問題解釋

根據您的評論，您的分片鍵是_id文件的欄位。這個欄位是單調遞增的，基本上就像一個遞增的整數。

簡而言之，分片以這種方式工作：文件儲存在塊中。這些塊根據分片鍵的範圍分佈在集群中。讓我們看一個簡單的例子：

• s1：持有 id 0-50 的塊
• s2：持有 id 51-100 的塊
• s3：大於 101 的塊？

這就是問題發生的地方：所有新文件都轉到一個分片。然後會發生新的塊一直被創建（因為塊具有固定的大小）。所以不僅所有的寫入都集中在一個伺服器上，這個伺服器還必須做一些成本工作。在達到某個門檻值後，集群將開始將塊移動到其他分片，但這只會平衡磁碟空間。在範例中，它可能如下所示：

• s1：持有 id 0-100 的塊
• s2：持有 id 101-200 的塊
• s3：持有 id 201-?

顯然，所有的寫操作還是會去s3。

什麼地方出了錯？

您選擇了錯誤的分片鍵。單調增加的分片鍵會導致上述問題。AltoughObjectId看起來像雜湊和，但它們不是. 它們是單調遞增的。

可以做什麼？

你需要一個更好的片鍵。由於在對集合進行分片後無法更改 shard key，因此遷移到新的 shard key 並不是一件簡單的事情。不過在mongoDB的ticket system中有相當詳細的說明。基本上，它是這樣工作的：

1. 從集群中刪除除一個分片之外的所有分片
2. 等待塊遷移完成
3. 關閉剩餘的分片
4. 通過mongos實例​​更改分片鍵
5. 重啟最後一個分片
6. 將其他分片添加到集群

引用自：https://dba.stackexchange.com/questions/69899