MongoDB简单副本集的测试

这一节主要对上一节搭建的副本集做一些简单的测试。

我们首先进入primary节点（37017），并向test.test集合里插入10W条数据：

1.    rs0:PRIMARY> for(var i=0;i<100000;i++){
2.     db.test.insert({"name":"zhanjindong"+i,"age":23}) 
3.    }

等数据插入完毕我们登入到两个secondary节点，发现数据已经同步过来了:

./bin/mongo -port 37018
2.    rs0:SECONDARY> db.getMongo().setSlaveOk();
3.    rs0:SECONDARY> db.test.count()
4.    100000

注意：在secondary节点上执行操作之前需要执行db.getMongo().setSlaveOk()命令，该设置允许连接从非master端读取数据。

secondary节点宕机:

模拟副本集中一个secondary节点宕机的情况，直接kill -9掉37018这个节点：

1.    kill -9 9508

然后再登录之前primary节点,再插入1W条数据：

1.    rs0:PRIMARY> for(var i=0;i<10000;i++){
2.     db.test.insert({"name":"zhanjindong"+i,"age":23}) 
3.    }

然后再将37018这个节点启起来，过一会就发现宕机的节点数据已经同步过来了：

1.    rs0:SECONDARY> db.getMongo().setSlaveOk()
2.    rs0:SECONDARY> db.test.count()
3.    110000

 

primary节点宕机:

再模拟primary节点宕机的情况：kill -9掉37017端口，这时查看监控页面：http://192.168.129.129:38018/_replSet/

可以看到37018已经成了primary节点。主界面宕机导致了整个集群发生一次election，实现了failover。等37017恢复了会自动成为secondary节点：

 

所有secondary节点宕机：

当所有secondary宕机，或者副本集中只剩下一台机器的时候，那么剩下的机器只能成为secondary节点，也就意味着整个集群智能进行读操作而不能进行写操作：

当集群从故障中恢复过来后，仍然的primary节点仍然是primary节点。

注意：当某个节点宕机后重新启动该节点会有一段的时间（时间长短视集群的数据量和宕机时间而定）导致整个集群中所有节点都成为secondary而无法进行写操作（如果应用程序没有设置相应的ReadReference也可能不能进行读取操作）。

 

因此官方推荐的最小的副本集也应该具备一个primary节点和两个secondary节点。两个节点的副本集不具备真正的故障转移能力。