【mongoDB運維篇④】Shard 分片集群

yy736044583 發布于2019-06-26 16:57 / 444人閱讀

摘要：簡述為何要分片減少單機請求數，降低單機負載，提高總負載減少單機的存儲空間，提高總存空間。就是用來存儲所有節點的配置信息每個的范圍在各的分布情況該集群中所有和的配置信息。

簡述 為何要分片

減少單機請求數，降低單機負載，提高總負載

減少單機的存儲空間，提高總存空間。

常見的mongodb sharding 服務器架構

要構建一個 MongoDB Sharding Cluster，需要三種角色：

Shard Server
即存儲實際數據的分片，每個Shard可以是一個mongod實例，也可以是一組mongod實例構成的Replication Set。為了實現每個Shard內部的auto-failover(自動故障切換)，MongoDB官方建議每個Shard為一組Replica Set。

Config Server
為了將一個特定的collection存儲在多個shard中，需要為該collection指定一個shard key(片鍵)，例如{age: 1} ，shard key可以決定該條記錄屬于哪個chunk(分片是以chunk為單位,后續會介紹)。Config Servers就是用來存儲：所有shard節點的配置信息、每個chunk的shard key范圍、chunk在各shard的分布情況、該集群中所有DB和collection的sharding配置信息。

Route Process
這是一個前端路由，客戶端由此接入，然后詢問Config Servers需要到哪個Shard上查詢或保存記錄，再連接相應的Shard進行操作，最后將結果返回給客戶端。客戶端只需要將原本發給mongod的查詢或更新請求原封不動地發給Routing Process，而不必關心所操作的記錄存儲在哪個Shard上。（所有操作在mongos上操作即可）

配置分片服務器

下面我們在同一臺物理機器上構建一個簡單的 Sharding Cluster：

Shard Server 1：27017
Shard Server 2：27018
Config Server ：27027
Route Process：40000

步驟一: 啟動Shard Server

mkdir -p ./data/shard/s0 ./data/shard/s1  #創建數據目錄
mkdir -p ./data/shard/log # 創建日志目錄

./bin/mongod --port 27017 --dbpath /usr/local/mongodb/data/shard/s0 --fork --logpath /usr/local/mongodb/data/shard/log/s0.log # 啟動Shard Server實例1

./bin/mongod --port 27018 --dbpath /usr/local/mongodb/data/shard/s1 --fork --logpath /usr/local/mongodb/data/shard/log/s1.log # 啟動Shard Server實例2

步驟二: 啟動Config Server

mkdir -p ./data/shard/config #創建數據目錄

./bin/mongod --port 27027 --dbpath /usr/local/mongodb/data/shard/config --fork --logpath /usr/local/mongodb/data/shard/log/config.log #啟動Config Server實例

注意，這里我們完全可以像啟動普通mongodb服務一樣啟動，不需要添加—shardsvr和configsvr參數。因為這兩個參數的作用就是改變啟動端口的，所以我們自行指定了端口就可以

步驟三: 啟動Route Process

./bin/mongos --port 4000 --configdb localhost:27027 --fork --logpath /usr/local/mongodb/data/shard/log/route.log --chunkSize=1 # 啟動Route Server實例

mongos啟動參數中，chunkSize這一項是用來指定chunk的大小的，單位是MB，默認大小為200MB，為了方便測試Sharding效果，我們把chunkSize指定為 1MB。意思是當這個分片中插入的數據大于1M時開始進行數據轉移

步驟四: 配置Sharding

# 我們使用MongoDB Shell登錄到mongos，添加Shard節點
./bin/mongo admin --port 40000 #此操作需要連接admin庫
> db.runCommand({ addshard:"localhost:27017" }) #添加 Shard Server 或者用 sh.addshard()命令來添加,下同;
{ "shardAdded" : "shard0000", "ok" : 1 }
> db.runCommand({ addshard:"localhost:27018" })
{ "shardAdded" : "shard0001", "ok" : 1 }

> db.runCommand({ enablesharding:"test" }) #設置分片存儲的數據庫
{ "ok" : 1 }

> db.runCommand({ shardcollection: "test.users", key: { id:1 }}) # 設置分片的集合名稱。且必須指定Shard Key，系統會自動創建索引，然后根據這個shard Key來計算
{ "collectionsharded" : "test.users", "ok" : 1 }

 > sh.status(); #查看片的狀態
 > printShardingStatus(db.getSisterDB("config"),1); # 查看片狀態(完整版);
 > db.stats(); # 查看所有的分片服務器狀態

注意這里我們要注意片鍵的選擇，選擇片鍵時需要根據具體業務的數據形態來選擇，切不可隨意選擇，實際中尤其不要輕易選擇自增_id作為片鍵，除非你很清楚你這么做的目的，具體原因我不在此分析，根據經驗推薦一種較合理的片鍵方式，“自增字段+查詢字段”，沒錯，片鍵可以是多個字段的組合。

另外這里說明一點，分片的機制：mongodb不是從單篇文檔的級別,絕對平均的散落在各個片上, 而是N篇文檔,形成一個塊"chunk",優先放在某個片上, 當這片上的chunk,比另一個片的chunk區別比較大時(>=3) ,會把本片上的chunk,移到另一個片上, 以chunk為單位,維護片之間的數據均衡。

也就是說，一開始插入數據時，數據是只插入到其中一塊分片上的，插入完畢后，mongodb內部開始在各片之間進行數據的移動，這個過程可能不是立即的，mongodb足夠智能會根據當前負載決定是立即進行移動還是稍后移動。
在插入數據后，立馬執行db.users.stats();兩次可以驗證如上所說。

這種分片機制,節省了人工維護成本,但是由于其是優先往某個片上插入,等到chunk失衡時,再移動chunk,并且隨著數據的增多,shard的實例之間,有chunk來回移動的現象,這將會為服務器帶來很大的IO開銷,解決這種開銷的方法,就是手動預先分片;

手動預先分片

以shop.user表為例

sh.shardCollection(‘shop.user’,{userid:1}); # user表用userid做shard key

for(var i=1;i<=40;i++) { sh.splitAt("shop.user",{userid:i*1000}) } # 預先在1K 2K...40K這樣的界限切好chunk(雖然chunk是空的), 這些chunk將會均勻移動到各片上.

通過mongos添加user數據. 數據會添加到預先分配好的chunk上, chunk就不會來回移動了.

repliction set and shard

一般mongoDB如果真的到了分片的級別后,那片服務器避無可免的要用到復制集,部署的基本思路同上,只需要注意兩點:

sh.addShard( host ) server:port OR setname/server:port # 如果是復制集的片服務器,我們應該復制集的名稱寫在前面比如
sh.addShard("ras/192.168.42.168:27017"); # 27017也就是復制集中的primary

另外在啟動本機的mongod服務的時候,最好把ip也給寫進去,否則有可能會有不可預知的錯誤;

文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。

轉載請注明本文地址：http://m.specialneedsforspecialkids.com/yun/18805.html

搭建 MongoDB分片（sharding） / 分區 / 集群環境

摘要：搭建分片分區集群環境安裝三臺機器關閉防火墻主節點副節點仲裁仲裁主節點副節點副節點仲裁主節點端口分配下載并且安裝所有版本二進制文件自行下載改名分別在每臺機器建立六個目錄，因為不存儲數據，只需要建立日志文件目錄即可。搭建 MongoDB分片（sharding） / 分區 / 集群環境 1. 安裝 MongoDB 三臺機器關閉防火墻 systemctl stop firewalld.se...

KunMinX 2019-06-26 17:34 評論0 收藏0
初識MongoDB分片

摘要：復制一份，命名為，修改文件內容如下注意改為我們第一步創建的目錄，端口號改為這個隨意，只要該端口沒被占用即可，表示這是一個配置服務器，另外由于我們的配置服務器要做成備份集，所以要設置。分片是指將數據拆分，拆分后存放在不同的機器上的過程，以此來降低單個服務器的壓力，同時也解決單個服務器硬盤空間不足的問題，讓我們可以用廉價的機器實現高性能的數據架構。有的小伙伴不理解分片和副本集的差異，一言...

Nino 2019-06-26 17:31 評論0 收藏0
TiDB和MongoDB分片集群架構比較

摘要：此文已由作者溫正湖授權網易云社區發布。分片集群通過就可以實現負載均衡，不需要單獨部署負載均衡組件。是一個集群，通過協議保持數據的一致性副本數量可配置，默認保存三副本，并通過做負載均衡調度。此文已由作者溫正湖授權網易云社區發布。歡迎訪問網易云社區，了解更多網易技術產品運營經驗。最近閱讀了TiDB源碼的說明文檔，跟MongoDB的分片集群做了下簡單對比。首先展示TiDB的整體架構 ...

KaltZK 2019-06-28 11:01 評論0 收藏0
UCloud MongoDB 如何應對高考填志愿的上億流量高峰

摘要：優志愿張海鵬宋體背景宋體每年月下旬到月下旬期間是高考填志愿的高峰期，也是優志愿后端面臨大流量高并發請求的業務高峰期。對于優志愿讀多寫少的場景及其業務高峰期，用戶可以按需增刪節點，更好地實現讀取性能的擴展。隨著用戶規模的增長，數據庫的壓力也在成倍增加。面對大流量、高并發，UCloud MongoDB 做到了高效，并展現出了更好的性能體驗。 —— 優志愿 CTO 張海鵬背景...

cppprimer 2019-10-29 15:13 評論0 收藏0
MongoDB分片部署實踐

摘要：本篇記錄高可用模式部署步驟，其他部署方式見上一篇。首先準備機器，我這里是在公司云平臺創建了三臺，分別是，，。分片的選擇策略可以參考官方文檔。本篇記錄MongoDB高可用模式部署步驟，其他部署方式見上一篇。首先準備機器，我這里是在公司云平臺創建了三臺DB server，ip分別是10.199.144.84，10.199.144.89，10.199.144.90。分別安裝mong...

孫淑建 2019-06-26 16:50 評論0 收藏0