本文介绍MongoDB副本集的搭建步骤与测试方法，包括数据复制与故障转移功能，并探讨了读写分离及副本集优化方案。
上篇博客介绍了主从复制，它虽然能做到备份、数据恢复，但是同样存在问题。下面看看MongoDb设计的副本集。主从模式其实就是一个单副本的应用，没有很好的扩展性和容错性。而副本集具有多个副本保证了容错性，就算一个副本挂掉了还有很多副本。如图：
从图中可以看到客户端连接到整个副本集，不关心具体哪台机器是否挂掉。主服务器负责整个副本集的读写，副本集定期同步数据备份，一旦主节点挂掉，副本节点就会选择一个新的主服务器。这一切对于应用服务器不需要关心。
副本集中的副本节点在主节点挂掉后通过心跳机制检测，会在集群内部发起主节点的投票选举机制，自动选举一位新的主服务器。
1、准备两台机器 192.168.1.136、192.168.1.137、192.168.1.138。 192.168.1.136 当作副本集主节点，192.168.1.137、192.168.1.138作为副本集副本节点。
2、分别在每台机器上建立mongodb副本集测试文件夹
#存放整个mongodb文件
mkdir -p /data/mongodbtest/replset
#存放mongodb数据文件
mkdir -p /data/mongodbtest/replset/data
#进入mongodb文件夹
cd /data/mongodbtest3、分别在每台机器上启动mongodb
/data/mongodbtest/mongodb-linux-x86_64-2.4.8/bin/mongod --dbpath /data/mongodbtest/replset/data --replSet repset 4.初始化副本集
在三台机器上任意一台机器登陆mongodb
/data/mongodbtest/mongodb-linux-x86_64-2.4.8/bin/mongo #使用admin数据库 use admin定义副本集配置变量，这里的 _id:”repset” 和上面命令参数“ –replSetrepset” 要保持一样。
<pre name="code" class="html">config = { _id:"repset", members:[
... {_id:0,host:"192.168.1.136:27017"},
... {_id:1,host:"192.168.1.137:27017"},
... {_id:2,host:"192.168.1.138:27017"}]
... }输出
<pre name="code" class="html"> {
"_id" : "repset",
"members" : [
{
"_id" : 0,
"host" : "192.168.1.136:27017"
},
{
"_id" : 1,
"host" : "192.168.1.137:27017"
},
{
"_id" : 2,
"host" : "192.168.1.138:27017"
}
]
} #初始化副本集配置 rs.initiate(config);
输出成功
{
"info" : "Config now saved locally. Should come online in about a minute.",
"ok" : 1
} <pre name="code" class="html">#查看集群节点的状态 rs.status();
<pre name="code" class="html"> {
"set" : "repset",
"date" : ISODate("2013-12-29T12:54:25Z"),
"myState" : 1,
"members" : [
{
"_id" : 0,
"name" : "192.168.1.136:27017",
"health" : 1,
"state" : 2,
"stateStr" : "SECONDARY",
"uptime" : 1682,
"optime" : Timestamp(1388319973, 1),
"optimeDate" : ISODate("2013-12-29T12:26:13Z"),
"lastHeartbeat" : ISODate("2013-12-29T12:54:25Z"),
"lastHeartbeatRecv" : ISODate("2013-12-29T12:54:24Z"),
"pingMs" : 1,
"syncingTo" : "192.168.1.138:27017"
},
{
"_id" : 1,
"name" : "192.168.1.137:27017",
"health" : 1,
"state" : 2,
"stateStr" : "SECONDARY",
"uptime" : 1682,
"optime" : Timestamp(1388319973, 1),
"optimeDate" : ISODate("2013-12-29T12:26:13Z"),
"lastHeartbeat" : ISODate("2013-12-29T12:54:25Z"),
"lastHeartbeatRecv" : ISODate("2013-12-29T12:54:24Z"),
"pingMs" : 1,
"syncingTo" : "192.168.1.138:27017"
},
{
"_id" : 2,
"name" : "192.168.1.138:27017",
"health" : 1,
"state" : 1,
"stateStr" : "PRIMARY",
"uptime" : 2543,
"optime" : Timestamp(1388319973, 1),
"optimeDate" : ISODate("2013-12-29T12:26:13Z"),
"self" : true
}
],
"ok" : 1
} 5.测试副本集数据复制功能
<pre name="code" class="html"><pre name="code" class="html">#在主节点192.168.1.138 上连接到终端：
mongo 127.0.0.1
#建立test 数据库。
use test;
往testdb表插入数据。
> db.testdb.insert({"test1":"testval1"})
#在副本节点 192.168.1.136、192.168.1.137 上连接到mongodb查看数据是否复制过来。
/data/mongodbtest/mongodb-linux-x86_64-2.4.8/bin/mongo 192.168.1.136:27017
#使用test 数据库。
repset:SECONDARY> use test;
repset:SECONDARY> show tables;
输出
<pre name="code" class="html">Sun Dec 29 21:50:48.590 error: { "$err" : "not master and slaveOk=false", "code" : 13435 } at src/mongo/shell/query.js:128 #mongodb默认是从主节点读写数据的，副本节点上不允许读，需要设置副本节点可以读。
repset:SECONDARY> db.getMongo().setSlaveOk();
#可以看到数据已经复制到了副本集。
repset:SECONDARY> db.testdb.find();
<ol start="1"><li class="alt"><span><span>#输出 </span></span></li><li><span>{ "_id" : ObjectId("52c028460c7505626a93944f"), "test1" : "testval1" }
</span></li></ol>
6.测试副本集故障转移功能
先停掉主节点mongodb 138，查看136、137的日志可以看到经过一系列的投票选择操作，137 当选主节点，136从137同步数据过来。
查看整个集群的状态，可以看到138状态不可达：
{
"set" : "repset",
"date" : ISODate("2013-12-29T14:28:35Z"),
"myState" : 2,
"syncingTo" : "192.168.1.137:27017",
"members" : [
{
"_id" : 0,
"name" : "192.168.1.136:27017",
"health" : 1,
"state" : 2,
"stateStr" : "SECONDARY",
"uptime" : 9072,
"optime" : Timestamp(1388324934, 1),
"optimeDate" : ISODate("2013-12-29T13:48:54Z"),
"self" : true
},
{
"_id" : 1,
"name" : "192.168.1.137:27017",
"health" : 1,
"state" : 1,
"stateStr" : "PRIMARY",
"uptime" : 7329,
"optime" : Timestamp(1388324934, 1),
"optimeDate" : ISODate("2013-12-29T13:48:54Z"),
"lastHeartbeat" : ISODate("2013-12-29T14:28:34Z"),
"lastHeartbeatRecv" : ISODate("2013-12-29T14:28:34Z"),
"pingMs" : 1,
"syncingTo" : "192.168.1.138:27017"
},
{
"_id" : 2,
"name" : "192.168.1.138:27017",
"health" : 0,
"state" : 8,
"stateStr" : "(not reachable/healthy)",
"uptime" : 0,
"optime" : Timestamp(1388324934, 1),
"optimeDate" : ISODate("2013-12-29T13:48:54Z"),
"lastHeartbeat" : ISODate("2013-12-29T14:28:35Z"),
"lastHeartbeatRecv" : ISODate("2013-12-29T14:28:23Z"),
"pingMs" : 0,
"syncingTo" : "192.168.1.137:27017"
}
],
"ok" : 1
} 再启动原来的主节点 138，发现138 变为 SECONDARY，还是137 为主节点 PRIMARY。
Sun Dec 29 22:21:06.619 [rsStart] replSet I am 192.168.1.138:27017
Sun Dec 29 22:21:06.619 [rsStart] replSet STARTUP2
Sun Dec 29 22:21:06.627 [rsHealthPoll] replset info 192.168.1.136:27017 thinks that we are down
Sun Dec 29 22:21:06.627 [rsHealthPoll] replSet member 192.168.1.136:27017 is up
Sun Dec 29 22:21:06.627 [rsHealthPoll] replSet member 192.168.1.136:27017 is now in state SECONDARY
Sun Dec 29 22:21:07.628 [rsSync] replSet SECONDARY
Sun Dec 29 22:21:08.623 [rsHealthPoll] replSet member 192.168.1.137:27017 is up
Sun Dec 29 22:21:08.624 [rsHealthPoll] replSet member 192.168.1.137:27017 is now in state PRIMARY 目前看起来支持完美的故障转移了，这个架构是不是比较完美了？其实还有很多地方可以优化，比如开头的第二个问题：主节点的读写压力过大如何解决？常见的解决方案是读写分离，mongodb副本集的读写分离如何做呢？
好，读写分离做好我们可以数据分流，减轻压力解决了“主节点的读写压力过大如何解决？”这个问题。不过当我们的副本节点增多时，主节点的复制压力会加大有什么办法解决吗？mongodb早就有了相应的解决方案。
其中的仲裁节点不存储数据，只是负责故障转移的群体投票
副本集就是有自动故障恢复功能的主从集群。主从集群和副本集群最为明显的区别是副本集没有固定的主节点，整个集群会选举出一个主节点，当其不能工作时变更到其他节点。
扫一扫
4864
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
