Mongodb集群初步测试

zhangpengfei00

一，测试原理
　　——————————————————————————————————
1，Sharding cluster介绍
　　这是一种可以水平扩展的模式，在数据量很大时性能卓越，实际大规模应用一般会采用该架构去构建mongodb系统。
　　要构建一个 MongoDB Sharding Cluster，需要三种角色：
　　Shard Server: mongod 实例，用于存储实际的数据块，实际生产环境中一个shard server角色可由几台机器组成一个replica set承担，防止主机单点故障。
　　Config Server: mongod 实例，存储了整个 Cluster Metadata，其中包括 chunk 信息。
　　Route Server: mongos 实例，前端路由，客户端由此接入，且让整个集群看上去像单一数据库，使前端应用可以透明使用。
Sharding架构图:

2，本次测试环境说明
　　4台机器安装centos5.6+MongoDB1.9.1
　　Ip地址分别为：192.168.3.4,192.168.3.21,192.168.3.29,192.168.3.79
　　replica set1端口为3500
　　replica set2端口为3600
　　config server端口为5000
　　mongos端口为5500
　　1，分别在2台机器上运行一个mongod实例组织为replica set1，作为cluster的node1。
　　2，再分别在2台机器上运行一个mongod实例组织为replica set2，作为cluster的node2。
　　3，分别在3台机器上运行一个mongod实例，作为3个config server。
　　4，用一台机器运行一个mongos进程，用于客户端连接使用。
主机端口信息shard01：192.168.3.4Mongod  shard11:3500
Mongod  shard12:3600
Mongod  Config1:5000shard02：192.168.3.21Mongod  shard21:3500
Mongod  shard22:3600
Mongod  Config2:5000shard03：192.168.3.29Mongod  Config3:5000shard04：192.168.3.79Mongos1:5500　　新建test数据库、c1集合作为测试使用，并开启shards对该数据库和集合的支持。
测试插入数据，结果如下图:

　　以上状态信息说明c1集合已经成功开启shards并插入了数据，图中“n1，n2”为shards代号。
二，测试内容
　　——————————————————————————————————
1,测试replica set中单个节点down机后情况
　　下图为down机前状态：

　　测试方法为kill掉左侧主机，查看右侧主机是否会自动竞争成为“PRIMARY”，结果如下图：

　　分析以上日志我们了解到，当kill掉replica set中原来的primary主机后，原secondary主机并不会主动成为primary。尝试重启被kill掉的进程，结果如下图：

　　结果表明，在一个由2个节点组成的replica  set中，primary主机down掉后，scondary不会自动成为primary，在被kill掉的进程重新启动后，原secondary主机才 能成为primary，其日志也明确表明在192.168.3.4:3500进程重启时，它认为另一成员应该被“选举”出，所以原secondary主机 才成为了primary。
　　分析其中的原因，我们可以了解到，replica  set中的“PRIMARY”是经过“选举”产生的，而这个选举需要由被称为“majority”的主机发起，所以一开始原secondary并没有成为 primary的原因是它发现set中无majority，所以“选举过程”无法进行。在192.168.3.4:3500重新启动后，选举开 始，192.168.3.21:3500(原secondary)被选举成为“PRIMARY”。
2,测试config server中单节点以及多节点down机后情况
　　仅关闭config3(192.168.3.29:5000)，测试写入数据正常，读取数据正常。
　　关闭config2(192.168.3.21:5000)和config3(192.168.3.29:5000)，测试写入数据正常，读取数据正常。
　　关闭所有config后，数据库无法打开。
3,测试shard单组down机后情况
　　关闭shard2中3500,3600端口进程后，数据库可以读取，但是无法写入。