在对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不是一个简单的话题,更包括容灾备份等问题,本人也没有什么实践经验,所以也只能说说一些理论的东西,但愿与你们共同交流学习。
按照惯例,要图文并茂,今天画的是坂田银时,相信园子里喜欢银魂的人不在少数,以前看到许多朋友都是银魂的头像。在孤独地编程、写做时,《银魂》彷佛支撑了不少人,毒舌吐槽的背后是一个个简单而又平凡的人生真谛,温暖人心。有兴趣的能够看看新世相的这篇文章《阁下想要保护的东西已是一片虚无》。
全栈路上,没有归途。