MongoDB数据库集群初步研究

——————————————————————————————————

这是一种可以水平扩展的模式，在数据量很大时性能卓越，实际大规模应用一般会采用该架构去构建mongodb系统。

要构建一个 MongoDB Sharding Cluster，需要三种角色：

Shard Server: mongod 实例，用于存储实际的数据块，实际生产环境中一个shard server角色可由几台机器组成一个replica set承担，防止主机单点故障。

Config Server: mongod 实例，存储了整个 Cluster Metadata，其中包括 chunk 信息。

Route Server: mongos 实例，前端路由，客户端由此接入，且让整个集群看上去像单一数据库，使前端应用可以透明使用。

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进程，用于客户端连接使用。

新建test数据库、c1集合作为测试使用，并开启shards对该数据库和集合的支持。

以上状态信息说明c1集合已经成功开启shards并插入了数据，图中“n1，n2”为shards代号。

——————————————————————————————————

下图为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后，数据库无法打开。

关闭shard2中3500,3600端口进程后，数据库可以读取，但是无法写入。