在對mongoDB的操做有了必定基礎後,終於能夠扯扯HA和架構這兩個高大上的概念了。在這以前固然還得弄清楚mongoDB的Key feature:Sharding。編程
Shard從邏輯上來講就是整個數據的一個子集,從物理來講就是管理這一子集的服務器。一個分片能夠包含多臺服務器。若一個分片包含多臺服務器則每臺服務器都有一份徹底相同的數據子集副本(Replica set)。緩存
分片是MongoDB強調的一個Feature。分片的目的就在於完成自動化集羣運維。mongoDB cluster須要三種角色,Sharding server /Config Server /Route。服務器
HA是個大話題,從一個簡單系統的部署爲點開始談談吧。架構
如圖所示,架構上一個mongoDB集羣須要上述三種角色,這三種角色分別對應三個進程:mongos,shardsvr mongod和config mongod。併發
figure1負載均衡
Step1:啓動shard server實例1與實例2運維
>mongod --shardsvr --port 20000 --dbpath=/data/shared/s0 --fork --logpath=/data/shard/log/s0.log --directoryperdbmemcached
>mongod --shardsvr --port 20001 --dbpath=/data/shared/s1 --fork --logpath=/data/shard/log/s1.log --directoryperdb性能 |
Step2:啓動Config Server實例學習
>mongod --configsvr --port 30000 --dbpath=/data/shared/config --fork --logpath=/data/shard/log/config.log --directoryperdb |
Step3:啓動Route Server實例
>mongos --port 40000 --configdb localhost:30000 --fork --logpath=/data/shared/log/route.log --chunkSize 64 |
其中chunkSize指定chunk大小,單位爲MB,默認大小爲200MB。
MongoDB auto-sharding解決了海量存儲和動態擴容問題,然而以上離真正的生產環境HA方案還差的遠。下面更進一步,搭建Replica Sets + Sharding解決方案,設計案例。
Case1:
表1 小型使用案例舉例
Host |
IP |
服務及端口分配 |
Server A |
192.168.3.231 |
Mongod shard1_1: 27017 Mongod shard2_1: 27018 Mongod config1: 20000 Mongos1: 30000 |
Server B |
192.168.3.232 |
Mongod shard1_2: 27017 Mongod shard2_2: 27018 Mongod config2: 20000 Mongos2: 30000 |
Server C |
192.168.3.233 |
Mongod shard1_3: 27017 Mongod shard2_3: 27018 Mongod config3: 20000 Mongos3: 30000 |
固然實際使用環境中的集羣系統確定更復雜,HA不是一個簡單的話題,更包括容災備份等問題,本人也沒有什麼實踐經驗,所以也只能說說一些理論的東西,但願與你們共同交流學習。
按照慣例,要圖文並茂,今天畫的是阪田銀時,相信園子裏喜歡銀魂的人不在少數,以前看到許多朋友都是銀魂的頭像。在孤獨地編程、寫做時,《銀魂》彷佛支撐了不少人,毒舌吐槽的背後是一個個簡單而又平凡的人生真諦,溫暖人心。有興趣的能夠看看新世相的這篇文章《閣下想要保護的東西已是一片虛無》。
全棧路上,沒有歸途。