MongoDB Replica Sets

娟斌心

　　MongoDB 支持在多个机器中通过异步复制达到故障转移和实现冗余。多机器中同一时刻只有一台是用于写操作。正是由于这个情况，为MongoDB 提供了数据一致性的保障。担当Primary 角色的机器能把读操作分发给slave。 MongoDB 高可用可用分两种:

• Master-Slave 主从复制：只需要在某一个服务启动时加上–master 参数，而另一个服务加上–slave 与–source 参数，即可实现同步。MongoDB 的最新版本已不再推荐此方案。
  
• Replica Sets复制集：MongoDB 在 1.6 版本对开发了新功能replica set，这比之前的replication 功能要强大一些，增加了故障自动切换和自动修复成员节点，各个DB 之间数据完全一致，大大降低了维护成功。auto shard 已经明确说明不支持replication paris，建议使用replica set，replica set故障切换完全自动。
  

　　

一、部署Replica Sets
　　目前有三台服务器，信息如下：

• replica set1: 192.168.8.204:28010
  
• replica set2:192.168.8.205:28010
  
• replica set3:192.168.8.206:28010
  

　　为简化操作，可以各节点基本配置相同。

1. 预备信息处理（各节点可以相同，也可以不同）



$mkdir -p /data/db/rs1  /data/db/log  /data/db/key  #创建所需目录
$echo "this is rs1 super secret key" >/data/db/key/rs1  #生成replica set 密钥文件
$chmod 600 /data/db/key/rs1  #调整密钥文件为当前用户只读权限
2.启动mongod实例
　　各节点执行如下命令启动mongod实例：



$bin/mongod --replSet rs1 --port 28010 --keyFile /data/db/key/rs1  --dbpath /data/db/rs1 --logpath /data/db/log/rs1.log --logappend --fork
3.配置及初始化Replica Set



$bin/mongo --port 28010
>config_rs1={_id:'rs1',members:[
                        {_id:204,host:'192.168.8.204:28010',priority:1},
                        {_id:205,host:'192.168.8.205:28010'},
                        {_id:206,host:'192.168.8.206:28010'}]}
>rs.initiate(config_rs1)  //初始化配置
4.查看复制集状态



>rs.status()
{
    "set" : "rs1",
    "date" : ISODate("2012-03-01T09:49:57Z"),
    "myState" : 1,
    "members" : [
        {
            "_id" : 204,
            "name" : "192.168.8.204:28010",
            "health" : 1, //1 表明正常; 0 表明异常
            "state" : 1, // 1 表明是Primary; 2 表明是Secondary;
            "stateStr" : "PRIMARY", //表明此机器是主库
            "optime" : {
                "t" : 1338457763000,
                "i" : 1
            },
            "optimeDate" : ISODate("2012-03-01T09:49:23Z"),
            "self" : true
        },
        {
            "_id" : 205,
            "name" : "192.168.8.205:28010",
            "health" : 1,
            "state" : 2,
            "stateStr" : "SECONDARY",
            "uptime" : 23,
            "optime" : {
                "t" : 1338457763000,
                "i" : 1
            },
            "optimeDate" : ISODate("2012-03-01T09:49:23Z"),
            "lastHeartbeat" : ISODate("2012-03-01T09:49:56Z")
        },
        {
            "_id" : 2,
            "name" : "192.168.8.206:28010",
            "health" : 1,
            "state" : 2,
            "stateStr" : "SECONDARY",
            "uptime" : 23,
            "optime" : {
                "t" : 1338457763000,
                "i" : 1
            },
            "optimeDate" : ISODate("2012-03-01T09:49:23Z"),
            "lastHeartbeat" : ISODate("2012-03-01T09:49:56Z")
        }
    ],
    "ok" : 1
}
　　还可以查看当前节点是否为Master节点：



PRIMARY>rs.isMaster()

二、主从操作日志oplog
　　MongoDB 的Replica Set 架构是通过一个日志来存储写操作的，这个日志就叫做”oplog”。oplog.rs 是一个固定长度的 capped collection，它存在于”local”数据库中，用于记录 Replica Sets 操作日志。在默认情况下,对于64 位的MongoDB,oplog 是比较大的，可以达到5%的磁盘空间。oplog 的大小是可以通过mongod 的参数”--oplogSize”来改变oplog 的日志大小。 样例如下：



rs1:PRIMARY>use local
rs1:PRIMARY> show collections
oplog.rs
system.replset
rs1:PRIMARY> db.oplog.rs.find()
{ "ts" : { "t" : 1338457763000, "i" : 1 }, "h" : NumberLong(0), "op" : "n", "ns" : "", "o" : { "msg" :"initiating set" } }
{ "ts" : { "t" : 1338459114000, "i" : 1 }, "h" : NumberLong("5493127699725549585"), "op" : "i","ns" : "test.c1",
           "o" : { "_id" : ObjectId("4fc743e9aea289af709ac6b5"), "age" : 29, "name" :"Tony" } }
　　字段说明:

• ts: 某个操作的时间戳
  
• op: 操作类型，如下： i: insert d: delete u: update
  
• ns: 命名空间，也就是操作的collection name
  
• o: document 的内容
  

　　查看Master的oplog元数据信息：



> rs.printReplicationInfo()
　　查看Slave的同步状态：



> rs.printSlaveReplicationInfo()
　　查看主从配置信息：



> rs.conf() //或db.system.replset.find()

三、管理维护Replica set

1. 读写分离
　　在主库插入数据，从从库查询数据，使从库拥有只读权限只有上述的基本配置是不够的，需要在从节点执行如下操作：



> db.getMongo().setSlaveOk()  //让从库可以读
2. 故障自动转移
　　复制集比传统的Master-Slave 有改进的地方就是他可以进行故障的自动转移，如果我们停掉复制集中的一个成员，那么剩余成员会再自动选举出一个成员，做为主库。

3. 增加节点
　　MongoDB Replica Sets 不仅提供高可用性的解决方案，它也同时提供负载均衡的解决方案，增减Replica Sets 节点在实际应用中非常普遍，例如当应用的读压力暴增时，3 台节点的环境已不能满足需求，那么就需要增加一些节点将压力平均分配一下；当应用的压力小时，可以减少一些节点来减少硬件资源的成本；总之这是一个长期且持续的工作。 增加节点，一种是通过oplog 来增加节点，一种是通过数据库快照(--fastsync)和oplog 来增加节点，下面将分别介绍。

3.1 通过oplog来增加节点
　　新增replica set 节点，配置和启动如上述步骤。下面将新加节点192.168.8.207：28010加入复制集中。



rs1:PRIMARY> rs.add({_id:207,host:"192.168.8.207:28010"})
rs1.PRIMARY> rs.status() //通过查看状态可知晓新增节点有以下过程

• 进行初始化：节点状态"status":6,"errmsg":"still initializing"
  
• 进行数据同步：节点状态"status":3,"errmsg":"initial sync need a member to be primary or secondary to do our initial sync"
  
• 初始化同步完成：节点状态"status":3,"errmsg":"initial sync done"
  
• 节点添加完成：节点状态"status":2
  

3.2数据库快照+oplog增加节点
　　通过oplog 直接进行增加节点操作简单且无需人工干预过多，但oplog 是capped collection，采用循环的方式进行日志处理，所以采用oplog 的方式进行增加节点，有可能导致数据的不一致，因为日志中存储的信息有可能已经刷新过了。不过没关系，我们可以通过数据库快照(--fastsync)和oplog 结合的方式来增加节点，这种方式的操作流程是，先取某一个复制集成员的物理文件来做为初始化数据，然后剩余的部分用oplog 日志来追，最终达到数据一致性。

• 取某一个复制集成员的物理文件来做为初始化数据
  
• 如前所述添加新复制集节点192.168.8.207：28010，实例增加选项--fastsync
  
• 使用oplog增加节点，验证数据一致性
  

　　

4.减少节点
　　使用如下命令删除复制集节点：



rs1:PRIMARY> rs.remove("192.168.8.206:28010")
rs1:PRIMARY&> rs.remove("192.168.8.207:28010")
rs1:PRIMARY> rs.status()