MongoDB数据库集群初步研究
一，测试原理
——————————————————————————————————
1，Sharding cluster介绍这是一种可以水平扩展的模式，在数据量很大时性能卓越，实际大规模应用一般会采用该架构去构建mongodb系统。
要构建一个 MongoDB Sharding Cluster，需要三种角色：
Shard Server: mongod 实例，用于存储实际的数据块，实际生产环境中一个shard server角色可由几台机器组成一个replica set承担，防止主机单点故障。
Config Server: mongod 实例，存储了整个 Cluster Metadata，其中包括 chunk 信息。
Route Server: mongos 实例，前端路由，客户端由此接入，且让整个集群看上去像单一数据库，使前端应用可以透明使用。
Sharding架构图:
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.4 |
Mongod shard11:3500 Mongod shard12:3600 Mongod Config1:5000 |
| shard02：192.168.3.21 |
Mongod shard21:3500 Mongod shard22:3600 Mongod Config2:5000 |
| shard03：192.168.3.29 | Mongod Config3:5000 |
| shard04：192.168.3.79 | Mongos1: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”。
仅关闭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端口进程后，数据库可以读取，但是无法写入。
MongoDB数据库集群初步研究
