分片簡(jiǎn)介
分片（shard）是指在將數(shù)據(jù)進(jìn)行水平切分之后，將其存儲(chǔ)到多個(gè)不同的服務(wù)器節(jié)點(diǎn)上的一種擴(kuò)展方式。分片在概念上非常類似于應(yīng)用開(kāi)發(fā)中的“水平分表”。不同的點(diǎn)在于，MongoDB 本身就自帶了分片管理的能力，對(duì)于開(kāi)發(fā)者來(lái)說(shuō)可以做到開(kāi)箱即用。
為什么要使用分片？
MongoDB 復(fù)制集實(shí)現(xiàn)了數(shù)據(jù)的多副本復(fù)制及高可用，但是一個(gè)復(fù)制集能承載的容量和負(fù)載是有限的。在你遇到下面的場(chǎng)景時(shí)，就需要考慮使用分片了：
- 存儲(chǔ)容量需求超出單機(jī)的磁盤容量。
- 活躍的數(shù)據(jù)集超出單機(jī)內(nèi)存容量，導(dǎo)致很多請(qǐng)求都要從磁盤讀取數(shù)據(jù)，影響性能。
- 寫 IOPS 超出單個(gè) MongoDB 節(jié)點(diǎn)的寫服務(wù)能力。
垂直擴(kuò)容（Scale Up） VS 水平擴(kuò)容（Scale Out）：
垂直擴(kuò)容：用更好的服務(wù)器，提高 CPU 處理核數(shù)、內(nèi)存數(shù)、帶寬等；
水平擴(kuò)容：將任務(wù)分配到多臺(tái)計(jì)算機(jī)上；
分片集群架構(gòu)
MongoDB 分片集群（Sharded Cluster）是對(duì)數(shù)據(jù)進(jìn)行水平擴(kuò)展的一種方式。MongoDB 使用分片集群來(lái)支持大數(shù)據(jù)集和高吞吐量的業(yè)務(wù)場(chǎng)景。在分片模式下，存儲(chǔ)不同的切片數(shù)據(jù)的節(jié)點(diǎn)被稱為分片節(jié)點(diǎn)，一個(gè)分片集群內(nèi)包含了多個(gè)分片節(jié)點(diǎn)。當(dāng)然，除了分片節(jié)點(diǎn)，集群中還需要一些配置節(jié)點(diǎn)、路由節(jié)點(diǎn)，以保證分片機(jī)制的正常運(yùn)作。
核心概念
- 數(shù)據(jù)分片
分片用于存儲(chǔ)真正的數(shù)據(jù)，并提供最終的數(shù)據(jù)讀寫訪問(wèn)。分片僅僅是一個(gè)邏輯的概念，它可以是一個(gè)單獨(dú)的 mongod 實(shí)例，也可以是一個(gè)復(fù)制集。圖中的 Shard1、Shard2 都是一個(gè)復(fù)制集分片。在生產(chǎn)環(huán)境中也一般會(huì)使用復(fù)制集的方式，這是為了防止數(shù)據(jù)節(jié)點(diǎn)出現(xiàn)單點(diǎn)故障。
- 配置服務(wù)器（Config Server）
配置服務(wù)器包含多個(gè)節(jié)點(diǎn)，并組成一個(gè)復(fù)制集結(jié)構(gòu)，對(duì)應(yīng)于圖中的 ConfigReplSet。配置復(fù)制集中保存了整個(gè)分片集群中的元數(shù)據(jù)，其中包含各個(gè)集合的分片策略，以及分片的路由表等。
- 查詢路由（mongos）
mongos 是分片集群的訪問(wèn)入口，其本身并不持久化數(shù)據(jù)。mongos 啟動(dòng)后，會(huì)從配置服務(wù)器中加載元數(shù)據(jù)。之后 mongos 開(kāi)始提供訪問(wèn)服務(wù)，并將用戶的請(qǐng)求正確路由到對(duì)應(yīng)的分片。在分片集群中可以部署多個(gè) mongos 以分擔(dān)客戶端請(qǐng)求的壓力。
環(huán)境搭建
分片集群搭建
使用 mtools 搭建分片集群。
使用分片集群
為了使集合支持分片，需要先開(kāi)啟 database 的分片功能
sh.enableSharding("shop")
執(zhí)行 shardCollection 命令，對(duì)集合執(zhí)行分片初始化
sh.shardCollection("shop.product",{productId:"hashed"},false,{numInitialChunks:4})
shop.product 集合將 productId 作為分片鍵，并采用了哈希分片策略，除此以外，“numInitialChunks：4”表示將初始化 4 個(gè) chunk。 numInitialChunks 必須和哈希分片策略配合使用。而且，這個(gè)選項(xiàng)只能用于空的集合，如果已經(jīng)存在數(shù)據(jù)則會(huì)返回錯(cuò)誤。
向分片集合寫入數(shù)據(jù)
向 shop.product 集合寫入一批數(shù)據(jù)
db=db.getSiblingDB("shop");
var count=0;
for(var i=0;i<1000;i++){
var p=[];
for(var j=0;j<100;j++){
p.push({
"productId":"P-"+i+"-"+j,
name:"羊毛衫",
tags:[
{tagKey:"size",tagValue:["L","XL","XXL"]},
{tagKey:"color",tagValue:["藍(lán)色","杏色"]},
{tagKey:"style",tagValue:"韓風(fēng)"}
]
});
}
count+=p.length;
db.product.insertMany(p);
print("insert ",count)
}
查詢數(shù)據(jù)的分布
db.product.getShardDistribution()
分片策略
通過(guò)分片功能，可以將一個(gè)非常大的集合分散存儲(chǔ)到不同的分片上。
假設(shè)這個(gè)集合大小是 1TB，那么拆分到 4 個(gè)分片上之后，每個(gè)分片存儲(chǔ) 256GB 的數(shù)據(jù)。這個(gè)當(dāng)然是最理想化的場(chǎng)景，實(shí)質(zhì)上很難做到如此絕對(duì)的平衡。一個(gè)集合在拆分后如何存儲(chǔ)、讀寫，與該集合的分片策略設(shè)定是息息相關(guān)的。在了解分片策略之前，我們先來(lái)介紹一下 chunk。
什么是 chunk
chunk 的意思是數(shù)據(jù)塊，一個(gè) chunk 代表了集合中的“一段數(shù)據(jù)”，例如，用戶集合（db.users）在切分成多個(gè) chunk 之后如圖所示：
chunk 所描述的是范圍區(qū)間，例如，db.users使用了 userId 作為分片鍵，那么 chunk 就是 userId 的各個(gè)值（或哈希值）的連續(xù)區(qū)間。集群在操作分片集合時(shí)，會(huì)根據(jù)分片鍵找到對(duì)應(yīng)的 chunk，并向該 chunk 所在的分片發(fā)起操作請(qǐng)求，而 chunk 的分布在一定程度上會(huì)影響數(shù)據(jù)的讀寫路徑，這由以下兩點(diǎn)決定：
- chunk 的切分方式，決定如何找到數(shù)據(jù)所在的 chunk
- chunk 的分布狀態(tài)，決定如何找到 chunk 所在的分片
分片算法
chunk 切分是根據(jù)分片策略進(jìn)行實(shí)施的，分片策略的內(nèi)容包括分片鍵和分片算法。當(dāng)前，MongoDB 支持兩種分片算法：
（1） 范圍分片（range sharding）
假設(shè)集合根據(jù) x 字段來(lái)分片，x 的完整取值范圍為 [minKey, maxKey] （x 為整數(shù)，這里的 minKey、maxKey 為整型的最小值和最大值），其將整個(gè)取值范圍劃分為多個(gè) chunk，例如：
- chunk1 包含 x 的取值在 [minKey，-75) 的所有文檔。
- chunk2 包含 x 取值在 [-75，25) 之間的所有文檔，依此類推。
范圍分片能很好地滿足范圍查詢的需求，比如想查詢 x 的值在 [-30，10] 之間的所有文檔，這時(shí) mongos 直接將請(qǐng)求定位到 chunk2 所在的分片服務(wù)器，就能查詢出所有符合條件的文檔。范圍分片的缺點(diǎn)在于，如果 Shard Key 有明顯遞增（或者遞減）趨勢(shì)，則新插入的文檔會(huì)分布到同一個(gè) chunk，此時(shí)寫壓力會(huì)集中到一個(gè)節(jié)點(diǎn)，從而導(dǎo)致單點(diǎn)的性能瓶頸。一些常見(jiàn)的導(dǎo)致遞增的 Key 如下：
- 時(shí)間值。
- ObjectId，自動(dòng)生成的 _id 由時(shí)間、計(jì)數(shù)器組成。
- UUID，包含系統(tǒng)時(shí)間、時(shí)鐘序列。
- 自增整數(shù)序列。
（2）哈希分片（hash sharding）
哈希分片會(huì)先事先根據(jù)分片鍵計(jì)算出一個(gè)新的哈希值（64 位整數(shù)），再根據(jù)哈希值按照范圍分片的策略進(jìn)行 chunk 的切分。適用于日志，物聯(lián)網(wǎng)等高并發(fā)場(chǎng)景。
哈希分片與范圍分片是互補(bǔ)的，由于哈希算法保證了隨機(jī)性，所以文檔可以更加離散地分布到多個(gè) chunk 上，這避免了集中寫問(wèn)題。然而，在執(zhí)行一些范圍查詢時(shí)，哈希分片并不是高效的。因?yàn)樗械姆秶樵兌急厝粚?dǎo)致對(duì)所有 chunk 進(jìn)行檢索，如果集群有 10 個(gè)分片，那么 mongos 將需要對(duì) 10 個(gè)分片分發(fā)查詢請(qǐng)求。哈希分片與范圍分片的另一個(gè)區(qū)別是，哈希分片只能選擇單個(gè)字段，而范圍分片允許采用組合式的多字段作為分片鍵。
哈希分片僅支持單個(gè)字段的哈希分片：
{ x : "hashed" }
{x : 1 , y : "hashed"} // 4.4 new
4.4 以后的版本，可以將單個(gè)字段的哈希分片和一個(gè)到多個(gè)的范圍分片鍵字段來(lái)進(jìn)行組合，比如指定 x:1，y 是哈希的方式。
分片標(biāo)簽
MongoDB 允許通過(guò)為分片添加標(biāo)簽（tag）的方式來(lái)控制數(shù)據(jù)分發(fā)。一個(gè)標(biāo)簽可以關(guān)聯(lián)到多個(gè)分片區(qū)間（TagRange）。均衡器會(huì)優(yōu)先考慮 chunk 是否正處于某個(gè)分片區(qū)間上（被完全包含），如果是則會(huì)將 chunk 遷移到分片區(qū)間所關(guān)聯(lián)的分片，否則按一般情況處理。
分片標(biāo)簽適用于一些特定的場(chǎng)景。例如，集群中可能同時(shí)存在 OLTP 和 OLAP 處理，一些系統(tǒng)日志的重要性相對(duì)較低，而且主要以少量的統(tǒng)計(jì)分析為主。為了便于單獨(dú)擴(kuò)展，我們可能希望將日志與實(shí)時(shí)類的業(yè)務(wù)數(shù)據(jù)分開(kāi)，此時(shí)就可以使用標(biāo)簽。
為了讓分片擁有指定的標(biāo)簽，需執(zhí)行 addShardTag 命令
sh.addShardTag("shard01","oltp")
sh.addShardTag("shard02","oltp")
sh.addShardTag("shard03","olap")
實(shí)時(shí)計(jì)算的集合應(yīng)該屬于 oltp 標(biāo)簽，聲明 TagRange
sh.addTagRange("main.devices",{shardKey:MinKey},{shardKey:MaxKey},"oltp")
而離線計(jì)算的集合，則屬于 olap 標(biāo)簽
sh.addTagRange("other.systemLogs",{shardKey:MinKey},{shardKey:MaxKey},"olap")
main.devices集合將被均衡地分發(fā)到 shard01、shard02 分片上，而other.systemLogs集合將被單獨(dú)
分發(fā)到 shard03 分片上。
分片鍵（ShardKey）的選擇
在選擇分片鍵時(shí)，需要根據(jù)業(yè)務(wù)的需求及范圍分片、哈希分片的不同特點(diǎn)進(jìn)行權(quán)衡。一般來(lái)說(shuō)，在設(shè)計(jì)分片鍵時(shí)需要考慮的因素包括：
- 分片鍵的基數(shù)（cardinality），取值基數(shù)越大越有利于擴(kuò)展。
以性別作為分片鍵 ：數(shù)據(jù)最多被拆分為 2 份；
以月份作為分片鍵 ：數(shù)據(jù)最多被拆分為 12 份；
- 分片鍵的取值分布應(yīng)該盡可能均勻。
- 業(yè)務(wù)讀寫模式，盡可能分散寫壓力，而讀操作盡可能來(lái)自一個(gè)或少量的分片。
- 分片鍵應(yīng)該能適應(yīng)大部分的業(yè)務(wù)操作。
分片鍵（ShardKey）的約束
ShardKey 必須是一個(gè)索引。非空集合須在 ShardCollection 前創(chuàng)建索引；空集合 ShardCollection 自動(dòng)創(chuàng)建索引。
4.4 版本之前：
- ShardKey 大小不能超過(guò) 512 Bytes；
- 僅支持單字段的哈希分片鍵；
- Document 中必須包含 ShardKey；
- ShardKey 包含的 Field 不可以修改。
-
4.4 版本之后:
- ShardKey 大小無(wú)限制；
- 支持復(fù)合哈希分片鍵；
- Document 中可以不包含 ShardKey，插入時(shí)被當(dāng) 做 Null 處理；
- 為 ShardKey 添加后綴 refineCollectionShardKey 命令，可以修改 ShardKey 包含的 Field；
而在 4.2 版本之前，ShardKey 對(duì)應(yīng)的值不可以修改；4.2 版本之后，如果 ShardKey 為非_id 字段，那么可以修改 ShardKey 對(duì)應(yīng)的值。
數(shù)據(jù)均衡
均衡的方式
一種理想的情況是，所有加入的分片都發(fā)揮了相當(dāng)?shù)淖饔茫ㄌ峁└蟮拇鎯?chǔ)容量，以及讀寫訪問(wèn)性能。因此，為了保證分片集群的水平擴(kuò)展能力，業(yè)務(wù)數(shù)據(jù)應(yīng)當(dāng)盡可能地保持均勻分布。這里的均勻性包含以下兩個(gè)方面：
- 所有的數(shù)據(jù)應(yīng)均勻地分布于不同的 chunk 上；
- 每個(gè)分片上的 chunk 數(shù)量盡可能是相近的；
其中，第 1 點(diǎn)由業(yè)務(wù)場(chǎng)景和分片策略來(lái)決定，而關(guān)于第 2 點(diǎn)，我們有以下兩種選擇：
- 手動(dòng)均衡
一種做法是，可以在初始化集合時(shí)預(yù)分配一定數(shù)量的 chunk（僅適用于哈希分片），比如給 10 個(gè)分片分配 1000 個(gè) chunk，那么每個(gè)分片擁有 100 個(gè) chunk。另一種做法則是，可以通過(guò) splitAt、moveChunk 命令進(jìn)行手動(dòng)切分、遷移。
- 自動(dòng)均衡
開(kāi)啟 MongoDB 集群的自動(dòng)均衡功能。均衡器會(huì)在后臺(tái)對(duì)各分片的 chunk 進(jìn)行監(jiān)控，一旦發(fā)現(xiàn)了不均衡狀態(tài)就會(huì)自動(dòng)進(jìn)行 chunk 的搬遷以達(dá)到均衡。其中，chunk 不均衡通常來(lái)自于兩方面的因素：
一方面，在沒(méi)有人工干預(yù)的情況下，chunk 會(huì)持續(xù)增長(zhǎng)并產(chǎn)生分裂（split），而不斷分裂的結(jié)果就會(huì)出現(xiàn)數(shù)量上的不均衡；
另一方面，在動(dòng)態(tài)增加分片服務(wù)器時(shí)，也會(huì)出現(xiàn)不均衡的情況。自動(dòng)均衡是開(kāi)箱即用的，可以極大簡(jiǎn)化集群的管理工作。
chunk 分裂
在默認(rèn)情況下，一個(gè) chunk 的大小為 64MB（MongoDB6.0 默認(rèn)是 128M），該參數(shù)由配置的 chunksize 參數(shù)指定。如果持續(xù)地向該 chunk 寫入數(shù)據(jù)，并導(dǎo)致數(shù)據(jù)量超過(guò)了 chunk 大小，則 MongoDB 會(huì)自動(dòng)進(jìn)行分裂，將該 chunk 切分為兩個(gè)相同大小的 chunk。
chunk 分裂是基于分片鍵進(jìn)行的，如果分片鍵的基數(shù)太小，則可能因?yàn)闊o(wú)法分裂而會(huì)出現(xiàn) jumbo chunk（超大塊）的問(wèn)題。例如，對(duì)db.users使用 gender （性別）作為分片鍵，由于同一種性別的用戶數(shù)可能達(dá)到數(shù)千萬(wàn)，分裂程序并不知道如何對(duì)分片鍵（gender）的一個(gè)單值進(jìn)行切分，因此最終導(dǎo)致在一個(gè) chunk 上集中存儲(chǔ)了大量的 user 記錄（總大小超過(guò) 64MB）。
jumbo chunk 對(duì)水平擴(kuò)展有負(fù)面作用，該情況不利于數(shù)據(jù)的均衡，業(yè)務(wù)上應(yīng)盡可能避免。一些寫入壓力過(guò)大的情況可能會(huì)導(dǎo)致 chunk 多次失?。╯plit），最終當(dāng) chunk 中的文檔數(shù)大于1.3×avgObjectSize時(shí)會(huì)導(dǎo)致無(wú)法遷移。此外在一些老版本中，如果 chunk 中的文檔數(shù)超過(guò) 250000 個(gè)，也會(huì)導(dǎo)致無(wú)法遷移。
自動(dòng)均衡
MongoDB 的數(shù)據(jù)均衡器運(yùn)行于 Primary Config Server（配置服務(wù)器的主節(jié)點(diǎn)）上，而該節(jié)點(diǎn)也同時(shí)會(huì)控制 chunk 數(shù)據(jù)的搬遷流程。
流程說(shuō)明：
- 分片 shard0 在持續(xù)的業(yè)務(wù)寫入壓力下，產(chǎn)生了 chunk 分裂。
- 分片服務(wù)器通知 Config Server 進(jìn)行元數(shù)據(jù)更新。
- Config Serve r的自動(dòng)均衡器對(duì) chunk 分布進(jìn)行檢查，發(fā)現(xiàn) shard0 和 shard1 的 chunk 數(shù)差異達(dá)到了閾值，向 shard0 下發(fā) moveChunk 命令以執(zhí)行 chunk 遷移。
- shard0 執(zhí)行指令，將指定數(shù)據(jù)塊復(fù)制到 shard1。該階段會(huì)完成索引、chunk 數(shù)據(jù)的復(fù)制，而且在整個(gè)過(guò)程中業(yè)務(wù)側(cè)對(duì)數(shù)據(jù)的操作仍然會(huì)指向 shard0；所以，在第一輪復(fù)制完畢之后，目標(biāo) shard1 會(huì)向 shard0 確認(rèn)是否還存在增量更新的數(shù)據(jù)，如果存在則繼續(xù)復(fù)制。
- shard0 完成遷移后發(fā)送通知，此時(shí) Config Server 開(kāi)始更新元數(shù)據(jù)庫(kù)，將 chunk 的位置更新為目標(biāo) shard1。在更新完元數(shù)據(jù)庫(kù)后并確保沒(méi)有關(guān)聯(lián) cursor 的情況下，shard0 會(huì)刪除被遷移的 chunk 副本。
- Config Server 通知 mongos 服務(wù)器更新路由表。此時(shí)，新的業(yè)務(wù)請(qǐng)求將被路由到 shard1。
遷移閾值
（1）mongodb4.4 遷移條件
均衡器對(duì)于數(shù)據(jù)的“不均衡狀態(tài)”判定是根據(jù)兩個(gè)分片上的 chunk 個(gè)數(shù)差異來(lái)進(jìn)行的。
| chunk個(gè)數(shù) | 遷移閾值 |
|---|---|
| 少于20 | 2 |
| 20～79 | 4 |
| 80及以上 | 8 |
https://www.mongodb.com/docs/v4.4/core/sharding-balancer-administration/
（2）mongodb6.0 遷移條件
如果碎片之間的數(shù)據(jù)差異（對(duì)于該集合）小于該集合配置范圍大小的三倍，則認(rèn)為該集合是平衡的。對(duì)于 128MB 的默認(rèn)范圍大小，對(duì)于給定的集合，兩個(gè)分片必須具有至少 384MB 的數(shù)據(jù)大小差異，才能進(jìn)行遷移。
https://www.mongodb.com/docs/v6.0/core/sharding-balancer-administration/
遷移速度
數(shù)據(jù)均衡的整個(gè)過(guò)程并不是很快，影響 MongoDB 均衡速度的幾個(gè)選項(xiàng)如下：
- _secondaryThrottle
用于調(diào)整遷移數(shù)據(jù)寫到目標(biāo)分片的安全級(jí)別。如果沒(méi)有設(shè)定，則會(huì)使用w：2選項(xiàng)，即至少一個(gè)備節(jié)點(diǎn)確認(rèn)寫入遷移數(shù)據(jù)后才算成功。從 MongoDB 3.4 版本開(kāi)始， _secondaryThrottle 被默認(rèn)設(shè)定為 false，chunk 遷移不再等待備節(jié)點(diǎn)寫入確認(rèn)。
- _waitForDelete
在 chunk 遷移完成后，源分片會(huì)將不再使用的 chunk 刪除。如果 _waitForDelete 是 true，那么均衡器需要等待 chunk 同步刪除后才進(jìn)行下一次遷移。該選項(xiàng)默認(rèn)為 false，這意味著對(duì)于舊 chunk 的清理是異步進(jìn)行的。
- 并行遷移數(shù)量
在早期版本的實(shí)現(xiàn)中，均衡器在同一時(shí)刻只能有一個(gè) chunk 遷移任務(wù)。從 MongoDB 3.4 版本開(kāi)始，允許 n 個(gè)分片的集群同時(shí)執(zhí)行 n/2 個(gè)并發(fā)任務(wù)。
隨著版本的迭代，MongoDB 遷移的能力也在逐步提升。從 MongoDB 4.0 版本開(kāi)始，支持在遷移數(shù)據(jù)的過(guò)程中并發(fā)地讀取源端和寫入目標(biāo)端，遷移的整體性能提升了約 40%。這樣也使得新加入的分片能更快地分擔(dān)集群的訪問(wèn)讀寫壓力。
數(shù)據(jù)均衡帶來(lái)的問(wèn)題
數(shù)據(jù)均衡會(huì)影響性能，在分片間進(jìn)行數(shù)據(jù)塊的遷移是一個(gè)“繁重”的工作，很容易帶來(lái)磁盤 I/O 使用率飆升，或業(yè)務(wù)時(shí)延陡增等一些問(wèn)題。因此，建議盡可能提升磁盤能力，如使用 SSD。除此之外，我們還可以將數(shù)據(jù)均衡的窗口對(duì)齊到業(yè)務(wù)的低峰期以降低影響。
登錄 mongos，在 config 數(shù)據(jù)庫(kù)上更新配置，代碼如下：
use config
sh.setBalancerState(true)
db.settings.update(
{_id:"balancer"},
{$set:{activeWindow:{start:"02:00",stop:"04:00"}}},
{upsert:true}
)
在上述操作中啟用了自動(dòng)均衡器，同時(shí)在每天的凌晨 2 點(diǎn)到 4 點(diǎn)運(yùn)行數(shù)據(jù)均衡操作。文章來(lái)源：http://www.zghlxwxcb.cn/news/detail-790742.html
對(duì)分片集合中執(zhí)行 count 命令可能會(huì)產(chǎn)生不準(zhǔn)確的結(jié)果，mongos 在處理 count 命令時(shí)會(huì)分別向各個(gè)分片發(fā)送請(qǐng)求，并累加最終的結(jié)果。如果分片上正在執(zhí)行數(shù)據(jù)遷移，則可能導(dǎo)致重復(fù)的計(jì)算。替代辦法是使用db.collection.countDocuments({})方法，該方法會(huì)執(zhí)行聚合操作進(jìn)行實(shí)時(shí)掃描，可以避免元數(shù)據(jù)讀取的問(wèn)題，但需要更長(zhǎng)時(shí)間。
在執(zhí)行數(shù)據(jù)庫(kù)備份的期間，不能進(jìn)行數(shù)據(jù)均衡操作，否則會(huì)產(chǎn)生不一致的備份數(shù)據(jù)。在備份操作之前，可以通過(guò)如下命令確認(rèn)均衡器的狀態(tài):文章來(lái)源地址http://www.zghlxwxcb.cn/news/detail-790742.html
sh.getBalancerState()：查看均衡器是否開(kāi)啟。
sh.isBalancerRunning()：查看均衡器是否正在運(yùn)行。
sh.getBalancerWindow()：查看當(dāng)前均衡的窗口設(shè)定。
到了這里，關(guān)于MongoDB分片集群架構(gòu)詳解的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
