什么是Primary Shard

在MongoDB的Sharding架構(gòu)中，每個database中都可以存儲兩種類型的集合，一種是未分片的集合，一種是通過分片鍵，被打散的集合。被分片鍵打散的集合數(shù)據(jù)可以均勻的分布在各個分片上；而對于未分片的集合，則只會存儲在所在的database的Primary Shard中，每個database有且只有一個Primary Shard。簡單來說就是，Primary Shard存儲了當前數(shù)據(jù)庫未分片的集合。示意圖如下：

其中Collection I為分片集合，數(shù)據(jù)被打散到不同的分片上。Collection 2作為未分片集合所有的所有都只存儲在Primary Shard中，這里它的Primary Shard為Shard A。

Primary Shard的選擇及問題

當我們通過mongos創(chuàng)建一個database時，mongos會根據(jù)當前每個分片中存儲的數(shù)據(jù)量來決定哪個分片為當前數(shù)據(jù)庫的Primary Shard，存儲數(shù)據(jù)量最少的作為當前數(shù)據(jù)庫的主分片。數(shù)據(jù)量判斷依據(jù)為listDatabases命令中的totalSize的值。

比如我們新建一個test1庫，并在里面創(chuàng)建一個未分片的集合，mongos為它挑選的Primary Shard為shard2：

[direct: mongos] test> use test1;
switched to db test1
[direct: mongos] test1> db.foo.insertOne({"name":"aaa"});
{
  acknowledged: true,
  insertedId: ObjectId("66c6f060b47ae218b4ef12aa")
}
[direct: mongos] test1> sh.status()
...
  {
    database: {
      _id: 'test1',
      primary: 'shard2',
      partitioned: false,
      version: {
        uuid: new UUID("a419673b-944b-4cdd-8d11-f3074bbf43fb"),
        timestamp: Timestamp({ t: 1724313695, i: 1 }),
        lastMod: 1
      }
    },
    collections: {}
  }

Primary Shard自動選擇存在的問題

問題一

假設有如下需求：有兩個專門存儲配置集合的database，由于是配置集合，所有數(shù)據(jù)量比較小，不需要再將其數(shù)據(jù)打散，但是為了方面管理，需要將這兩個配置庫存放在同一個分片中。換句話說就是這兩個配置庫的Primary Shard需要為同一個。

我們知道，mongos在選擇Primary Shard的時候是根據(jù)當前各個分片現(xiàn)有的數(shù)據(jù)量來決定的，但是如果當前各個分片的數(shù)據(jù)量都比較均衡，當我們的業(yè)務數(shù)據(jù)在持續(xù)變動的過程中，mongos在選擇Primary Shard的時候就會表現(xiàn)出隨機性--先后創(chuàng)建的database的Primary Shard極有可能會是不同的分片。

問題二

假設目前需要有一個日志庫，然后每個月都會以月份為后綴進行切庫，就是說6月份的話我會創(chuàng)建一個叫DB_202406的庫，7月份的話會創(chuàng)建一個叫做DB_202407的庫，集合的月增量為1個T。由于增量比較大，后面肯定是需要不斷加機器擴容的，當單臺服務器的磁盤IO能力不是瓶頸的情況下，為了后期加機器擴容時不需要進行歷史數(shù)據(jù)的均衡，所以日志集合的選擇了未分片。那么當我進行月底切庫，即創(chuàng)建新庫的時候，mongos就會判斷各個分片上的現(xiàn)有數(shù)據(jù)量，然后找一個數(shù)據(jù)量相對較小的分片作為Primary Shard，此時，如果各個分片的服務器磁盤并不是相同大小的，比如說A分片的磁盤大小為10T，B分片磁盤的大小為5T，但是A分片存儲的數(shù)據(jù)為4.8T，B分片存儲的數(shù)據(jù)為4.5T，這時候由于B分片上存儲的數(shù)據(jù)少，mongos會將B分片選為新庫的Primary Shard，但是實際情況是B分片所在的主機空閑空間已經(jīng)完全不足以支持本月的月增數(shù)據(jù)量了，后面就只能臨時擴容本機或刪數(shù)據(jù)或?qū)?shù)據(jù)在線同步遷移到有足夠空間的新機器上，并進行應用切換。

如何解決

針對上面存在的兩個問題，根本原因還是由于在新建庫后，mongs自動為當前庫選擇的Primary Shard可能會出現(xiàn)不合理性，所以我們在進行建庫的時候，最好的辦法是直接指定新庫的Primary Shard，這樣就可以規(guī)避掉上面兩個問題。而且針對第二個問題，還需要做的是當業(yè)務上線前需要做好的架構(gòu)規(guī)劃和容量規(guī)劃等。

建庫后指定當前庫的Primary Shard：

[direct: mongos] test> use DB1
switched to db DB1
[direct: mongos] DB1> sh.enableSharding("DB1","shard1") 
{
  ok: 1,
  '$clusterTime': {
    clusterTime: Timestamp({ t: 1724317769, i: 3 }),
    signature: {
      hash: Binary(Buffer.from("0000000000000000000000000000000000000000", "hex"), 0),
      keyId: Long("0")
    }
  },
  operationTime: Timestamp({ t: 1724317769, i: 1 })
}
[direct: mongos] DB1> sh.status()
...
  {
    database: {
      _id: 'DB1',
      primary: 'shard1',
      partitioned: false,
      version: {
        uuid: new UUID("ec0e50b8-3029-4333-887b-9ca0b54c4e20"),
        timestamp: Timestamp({ t: 1724317768, i: 1 }),
        lastMod: 1
      }
    },
    collections: {}
  }

只能在use新庫之后，立即指定新庫的Primary Shard，不能等創(chuàng)建過集合并寫入數(shù)據(jù)之后再指定，因為那時mongos已經(jīng)為新庫選好了Primary Shard，就不支持再次修改了

[direct: mongos] DB1> sh.enableSharding("DB1","shard3") 
MongoServerError: Database DB1 could not be created :: caused by :: database already created on a primary which is different from shard1

到此這篇關于MongoDB中的Primary Shard的文章就介紹到這了,更多相關MongoDB Primary Shard內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！

最新評論