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 新手,所以我使用下一篇文章來配置我的分片:
請檢查第一個接受的答案。或者我怎樣才能自己破解我的分片鍵?
問題解釋
根據您的評論,您的分片鍵是
_id
文件的欄位。這個欄位是單調遞增的,基本上就像一個遞增的整數。簡而言之,分片以這種方式工作:文件儲存在塊中。這些塊根據分片鍵的範圍分佈在集群中。讓我們看一個簡單的例子:
- s1:持有 id 0-50 的塊
- s2:持有 id 51-100 的塊
- s3:大於 101 的塊?
這就是問題發生的地方:所有新文件都轉到一個分片。然後會發生新的塊一直被創建(因為塊具有固定的大小)。所以不僅所有的寫入都集中在一個伺服器上,這個伺服器還必須做一些成本工作。在達到某個門檻值後,集群將開始將塊移動到其他分片,但這只會平衡磁碟空間。在範例中,它可能如下所示:
- s1:持有 id 0-100 的塊
- s2:持有 id 101-200 的塊
- s3:持有 id 201-?
顯然,所有的寫操作還是會去s3。
什麼地方出了錯?
您選擇了錯誤的分片鍵。單調增加的分片鍵會導致上述問題。Altough
ObjectId
看起來像雜湊和,但它們不是. 它們是單調遞增的。可以做什麼?
你需要一個更好的片鍵。由於在對集合進行分片後無法更改 shard key,因此遷移到新的 shard key 並不是一件簡單的事情。不過在mongoDB的ticket system中有相當詳細的說明。基本上,它是這樣工作的:
- 從集群中刪除除一個分片之外的所有分片
- 等待塊遷移完成
- 關閉剩餘的分片
- 通過
mongos
實例更改分片鍵- 重啟最後一個分片
- 將其他分片添加到集群