Performance

MongoDB中一個分片的重負載

  • October 20, 2015

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

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