前言
分片（sharding）是MongoDB將大型集合分割到不同服務器（或者說集群）上所采用的方法，主要為應對高吞吐量與大數(shù)據(jù)量的應用場景提供了方法。
將數(shù)據(jù)分散到不同的機器上，不需要功能強大的服務器就可以存儲更多的數(shù)據(jù)和處理更大的負載。基本思想就是將集合切成小塊，這些塊分散到若干片里，每個片只負責總數(shù)據(jù)的一部分，最后通過一個均衡器來對各個分片進行均衡（數(shù)據(jù)遷移）。通過一個名為mongos的路由進程進行操作，mongos知道數(shù)據(jù)和片的對應關(guān)系（通過配置服務器）。大部分使用場景都是解決磁盤空間的問題，對于寫入有可能會變差（+++里面的說明+++），查詢則盡量避免跨分片查詢。
使用分片的時機：
1，機器的磁盤不夠用了。使用分片解決磁盤空間的問題。
2，單個mongod已經(jīng)不能滿足寫數(shù)據(jù)的性能要求。通過分片讓寫壓力分散到各個分片上面，使用分片服務器自身的資源。
3，想把大量數(shù)據(jù)放到內(nèi)存里提高性能。和上面一樣，通過分片使用分片服務器自身的資源。
和既有的分庫分表、分區(qū)方案相比，MongoDB的最大區(qū)別在于它幾乎能自動完成所有事情，只要告訴MongoDB要分配數(shù)據(jù)，它就能自動維護數(shù)據(jù)在不同服務器之間的均衡。
一. 分片的集群組件
1.Mongos 【路由】
作為請求的訪問入口，所有的請求都由mongos來路由、分發(fā)、合并，這些動作對客戶端driver透明，用戶連接mongos就像連接mongod一樣使用。Mongos會根據(jù)請求類型及shard key將請求路由到對應的Shard。
2.Config Server 【配置服務器】
存儲Sharding Cluster 的所有元數(shù)據(jù)，所有的元數(shù)據(jù)都存儲在config數(shù)據(jù)庫；
*保存每個分片上的chunk的信息 * 保存chunk上的片鍵范圍。
3. Shard 【分片】
存儲應用數(shù)據(jù)記錄。
二. 分片優(yōu)勢
1.對集群進行抽象，讓集群“不可見”，分片對應用系統(tǒng)是透明的。
Mongos是專有路由進程，其會將客戶端發(fā)來的請求準確無誤的路由到集群中的一個或者一組服務器上，同時會把接收到的響應拼裝起來發(fā)回到客戶端。
2.保證集群總是可讀寫
將MongoDB的分片和復制集功能結(jié)合使用，在確保數(shù)據(jù)分片到多臺服務器的同時，也確保了每分數(shù)據(jù)都有相應的備份，可以確保有服務器壞掉時，其他的從庫可以立即接替壞掉的部分繼續(xù)工作。提高了集群的可用性和可靠性。
3.使集群易于擴展
當系統(tǒng)需要更多的空間和資源的時候，MongoDB使我們可以按需方便的擴充系統(tǒng)容量。
三. 分片部署注意事項（常見錯誤）
1.配置可復制集作為分片節(jié)點與配置單獨使用的可復制集基本一樣。但啟動參數(shù)中需指定—shardsvr參數(shù)。
否則，在啟動數(shù)據(jù)庫分片時報錯： {"code" : 193,"ok" : 0, "errmsg" : "Cannot accept sharding commands if not started with --shardsvr“} 。
2.創(chuàng)建配置服務器集群時，不能設(shè)置見證節(jié)點。
否則，報錯 "errmsg" : "Arbiters are not allowed in replica set configurations being used for config servers" 。
3.配置Mongos 實例時，請不要配置dbpath參數(shù)。
否則，設(shè)置dbpath參數(shù)，服務無法正常啟動，報錯：Error parsing INI config file: unrecognised option 'dbpath'。
4.配置Mongos 實例時，需設(shè)置Keyfile。
否則，不設(shè)置Keyfile，Service無法正常啟動， 報錯：2018-05-10T15:30:26.791+0800 W SHARDING [mongosMain] Error initializing sharding state, sleeping for 2 seconds and trying again :: caused by :: Unauthorized: Error loading clusterID :: caused by :: not authorized on config to execute command { find: “version”, readConcern: { level: “majority”, afterOpTime: { ts: Timestamp 1525937413000|2, t: 1 } }, maxTimeMS: 30000
5.分片集合設(shè)置。
分片不會默認生成，需要先在數(shù)據(jù)庫中啟動分片（sh.enableSharding(“DBName”) ），然后再設(shè)置集合分片（sh.shardCollection(“Collection”{片鍵}) ）
四. 分片管理的注意事項（常用命令）
1.檢查shards 配置及狀態(tài)
|
1
|
db.runCommand({listshards:1}) |
2. 檢查數(shù)據(jù)庫主片的地址以及是否分區(qū)
|
1
|
db.getSiblingDB("config").databases.find() |
3. 檢查數(shù)據(jù)塊的數(shù)量
db.chunks.count() --需切換到配置數(shù)據(jù)庫（config）
4. 查看分片的詳細信息，包括數(shù)據(jù)庫信息和范圍信息
|
1
|
sh.status() |
5. 索引是優(yōu)化查詢性能的重要手段。當在分片集合上聲明索引時，每個分片都會為自己的集合部分定義單獨的索引。分片集合只允許在_id字段和分片鍵上建立唯一索引。
6. 分割和遷移 MongoDB底層依賴2個機制來保持集群的平衡：分割和遷移。
分割是把一個大的數(shù)據(jù)塊分割為2個更小的數(shù)據(jù)塊的過程。遷移就是在分片之間移動數(shù)據(jù)塊的過程。當某些分片服務器包含的數(shù)據(jù)塊數(shù)據(jù)量大大超過其他分片服務器時就會觸發(fā)遷移的過程，這個觸發(fā)器叫做遷移回合（migration round）
6.1 遷移觸發(fā)條件
6.2 查看Balancer 進程是否開啟 sh.getBalancerState()
6.3 停Balancer 進程 sh.stopBalancer()和開啟Balancer 進程
6.4. 默認情況下 Balancer 進程一直在運行，為了降低Balancer進程對系統(tǒng)的運行，可以為Balancer進程設(shè)置運行時間窗口，讓Balancer進程在指定的時間窗口操作。
6.4.1 例如設(shè)置Balancer進程在23:00到6:00時間窗口內(nèi)執(zhí)行。
|
1
|
db.settings.update({ _id : "balancer" }, { $set : { activeWindow : { start : "23:00", stop : "6:00" } } }, true ) ; |
6.4.2 刪除Balancer進程運行時間窗口
6.5. 查看塊的范圍
6.5.1 如果集合數(shù)據(jù)量較小，可以直接通過sh.status()查看
6.5.2 如果集合數(shù)據(jù)量較大，sh.status()無法反應此集合的分塊信息。此時，可通過執(zhí)行以下命令查看printShardingStatus(db.getSisterDB("config"),1);
6.5.3 也可將命令切換到config數(shù)據(jù)庫下，執(zhí)行db.chunks.find()查看?？梢暂斎胫贫▍?shù)，例如，查看分片repsms2，集合cloud-docs.PushMessageRecord的塊情況（cloud-docs為數(shù)據(jù)庫名稱）
|
1
|
db.chunks.find({"shard" : "repsms2","ns" : "cloud-docs.PushMessageRecord"}).pretty() |
五. 備注
分片集群管理的數(shù)據(jù)量比較大，并且分片的架構(gòu)相對比較復雜。所以，一定在業(yè)務需求需要上分片時，再上分片，且不可準求“炫”的技術(shù)而上分片。另外，上線后，相關(guān)的監(jiān)控一定要部署，逐漸完善。
總結(jié)
以上就是這篇文章的全部內(nèi)容了，希望本文的內(nèi)容對大家的學習或者工作具有一定的參考學習價值，如果有疑問大家可以留言交流，謝謝大家對服務器之家的支持。
原文鏈接：https://www.cnblogs.com/xuliuzai/p/9620163.html
