標籤:
在對mongoDB的操作有了一定基礎後,終於可以扯扯HA和架構這兩個高大上的概念了。在這之前當然還得弄清楚mongoDB的Key feature:Sharding。
1. Sharding
Shard從邏輯上來說就是整個資料的一個子集,從物理來說就是管理這一子集的伺服器。一個分區可以包含多台伺服器。若一個分區包含多台伺服器則每台伺服器都有一份完全相同的資料子集副本(Replica set)。
分區是MongoDB強調的一個Feature。分區的目的就在於完成自動化叢集營運。mongoDB cluster需要三種角色,Sharding server /Config Server /Route。
2. HA
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 --directoryperdb >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:
- Shard:使用Replica Sets,確保每個資料節點都具有備份、自動容錯轉移、自動回復能力。
- Config Server:使用3個設定管理員,確保中繼資料完整性,存放key的對應關係。
- Route Server:使用方法3個路由進程,實現負載平衡,提高用戶端的接入效能及並發度。
- 搭建上述叢集完畢後,可以加入memcached伺服器,將高訪問量的資料緩衝在記憶體中,避免高頻度的磁碟I/O,從而進一步提升效能。
表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不是一個簡單的話題,更包括容災備份等問題,本人也沒有什麼實踐經驗,因此也只能說說一些理論的東西,希望與大家共同交流學習。
按照慣例,要圖文並茂,今天畫的是阪田銀時,相信園子裡喜歡銀魂的人不在少數,之前看到許多朋友都是銀魂的頭像。在孤獨地編程、寫作時,《銀魂》似乎支撐了很多人,毒舌吐槽的背後是一個個簡單而又平凡的人生真諦,溫暖人心。有興趣的可以看看新世相的這篇文章《閣下想要保護的東西已經是一片虛無》。
全棧路上,沒有歸途。
MongoDB自學日記3——架構及HA