mongodb 副本集搭建实现读写分享

Mongodb副本集配置
副本集就是有自动故障恢复功能的主从集群。主从集群和副本集最为明显的区别就是副本集没有固定的主节点。可以把副本集当做一个集群，整个集群会选出一个主节点，当其不能正常工作时则会激活其它节点。
系统：ＣentOS 5.6 x86_64mongo版本：mongodb-linux-x86_64-2.0.6.tgz Server1 10.0.1.121:20001server2 10.0.1.212:20001Arbiter 10.0.1.212:20002
目录规划：数据目录和日志单分出来Server1:/mongodb/mlogs应用程序日志统计放到/usr/local/mongoServer2:/mongodb/mlogs/arbiter应用程序日志统计放到/usr/local/mongo
部署：1.防火墙开启20001端口，关闭selinux
2.分别在两台机器上安装mongo服务tar xf mongodb-linux-x86_64-2.0.6.tgz -C /usr/local/mongo3.创建key文件Server1:mkdir /etc/keysecho "test123456" > r0Server2:mkdir /etc/keysecho "test123456" > r1Arbiter:echo "test123456" > r2chmod 600 r0 r1 r24.分别启动Server1和Server2的mongo服务Server1:/usr/local/mongo/bin/mongod --replSet rs1 --keyFile /usr/local/mongo/key/r0 --port 20001 --fork --dbpath=/mongodb/ --logpath /mlogs/Server1.log --fork为后台启动netstat -tunlp | grep mongo 查看端口是否被开启加入到开机启动脚本 /etc/rc.localServer2:/usr/local/mongo/bin/mongod --replSet rs1 --keyFile /usr/local/mongo/key/r1 --port 20001 --fork --dbpath=/mongodb/ --logpath /mlogs/Server2.log netstat -tunlp | grep mongo 查看端口是否被开启
/usr/local/mongo/bin/mongod --replSet rs1 --keyFile /usr/local/mongo/key/r2 --port 20002 --fork --dbpath=/arbiter --logpath /mlogs/arbiter.log
加入到开机启动脚本 /etc/rc.local使机器重启后继续生效
选项：--only在从节点上指定复制某个数据库（默认复制所有数据库）--slavedelay用在从节点上，当应用主节点的操作时增加延时（秒）--fastsync以主节点的数据快照为基础启动从节点，如果数据目录一开始是主节点的数据快照，从节点用这个选项启动要比完整同步快多了--autoresync如果从节点与主节点不同步，则自动重新同步--oplogSize主节点oplog的大小（MB）5.配置及初始化Replica Sets > config_pongo={..._id:'pongo',members:[...{_id:0,host:'10.0.1.121:20001',priority:1}, #如果有多个节点继续往下增加...{_id:1,host:'10.0.1.212:20001',priority:2}, ...{_id:2,host:"10.0.1.212:20002",arbiterOnly : true}]...}rs.initiate(config_rs1); 初始化Replica Sets
注：关于扩展节点和添加仲裁设备请看最下方、副本集中节点的类型standard:常规节点，它存储一份完整的数据副本，参与选举投票可以成为活跃节点。passive:存储了完整的数据副本，参与投票，不能成为活跃节点。arbiter:仲裁者只参与投票，不能接受复制数据，也不能成为活跃节点。每个参与节点（非仲裁者）都有个优先权，优先权为0是被动的，不能成为活跃节点，优先值不为0，则按照大小选出活跃节点。如果2个值一样，则数据最新的为活跃节点。在节点配置中修改priority键，来配置成标准节点或被动节点。
注：如果配置成功master会变成PRIMARY slave会变成SECONDARY
6.使用rs.status()查看副本集的状态信息
"health" : 1, --1表明正常; 0表明异常、"state" : 1, -- 1表明是Primary; 2 表明是Secondary;"stateStr" : "PRIMARY", --表明此机器是主库

主从操作日志oplog 主节点的操作记录称为oplog(operation log)。Oplog存储在一个特殊的数据库中，叫做local。Oplog就在其中的oplog.$main集合里面。Oplog中的每个文档都代表主节点执行的一个操作。MongoDB的 Replica Set 架构是通过一个日志来存储写操作的，这个日志就叫做”oplog”。oplog.rs是一个固定长度的 capped collection，它存在于”local”数据库中,用于记录Replica Sets操作日志。oplog的大小是可以通过mongod的参数”--oplogSize”来改变oplog的日志大小。
Oplog内容样例:rs1:PRIMARY> db.oplog.rs.find() local数据库中ts: 某个操作的时间戳 op: 操作类型,只有1字节代码，如下： i: insert d: delete u: update ns: 命名空间，也就是操作的collection name o: document的内容
查看master 的oplog元数据信息：rs1:PRIMARY> db.printReplicationInfo() configured oplog size: 配置的oplog文件大小 log length start to end: oplog日志的启用时间段 oplog first event time: 产生时间 oplog last event time: 最后一个事务日志的产生时间now: 现在的时间
注意：oplog不记录查询操作，oplog存储在固定集合里面，所以它们会自动替换旧的操作。 我们在启动服务器的时候可以用--oplogSize指定这个大小（MB）查看slave的同步状态rs1:PRIMARY> db.printSlaveReplicationInfo() source: 从库的IP及端口 syncedTo: 目前的同步情况，延迟了多久等信息 主从配置信息
主从配置信息 在local库中还有一个集合用于记录主从配置信息system.replsetrs1:PRIMARY> db.system.replset.find()
管理维护Replica Sets读写分离、从库要是进行查询，分担主库的大量的查询请求1)先向主库中插入一条测试数据2)在从库进行查询等操作3)让从库可以读，分担主库的压力执行db.getMongo().setSlaveOk()，我们就可查询从库了
故障转移 副本集比传统的Master-Slave 有改进的地方就是它可以进行故障的自动转移，如果我们停掉复制集中的一个成员，那么剩余成员会再自动选举出一个成员，做为主库。1)杀掉Server1 20001 端口的MongoDB2)查看副本集状态 rs.status()

重新同步如果从节点的数据被主节点的数据拉开太远了，则从节点可能跟不上主节点的步子，有可能造成同步失败。解决方法是从新进行同步{"resync":1}，也可以在启动从节点的时候用--autoresync选项让其自动启动。建议oplog的大小是剩余磁盘空间的5%。复制状态和本地数据库本地数据库（local）用来存放所有内部复制状态。其内容不会被复制，从而确保了一个MongoDB服务器只有一个本地数据库。管理诊断当连接到主节点后，使用db.printReplicationInfo函数>db.printReplicationInfo(); 这些信息是oplog的大小和oplog中操作的时间范围。当连接到从节点时，用db.printSlaveReplicationInfo()函数，能得到从节点的一些信息。变更oplog的大小若发现oplog大小不适合，最简单的方法是停掉主节点，删除local数据库的文件，用新的设置(--oplogSize)重新启动。$ rm /data/db/local.*$ ./mongod --master --oplogSize size(新大小)重启主节点后，所有的从节点要用--autoresync重启，否则需要手动同步更新

当在副本集中添加和删除节点时，需要的操作流程：
1、利用另外一台secondary机器传送数据2、在新机器上中配置文件中添加fastsync=true配置（当需要从有数据中启动节点，那么必须加上fastsync=true，否则启动会报错，如果是从主库直接同步所有数据，那么就不需要添加这个参数）3、启动后，在primary节点中添加节点如：rs.add({_id:2,host:"10.100.100.202:19753",priority:2) 当我们看到变为secondary后，就一切正常，可以正常提供线上服务了4、通过rs.conf()命令查看现在的节点信息（需要admin库密码权限）5、rs.remove()删除节点(rs.remove("10.100.100.202:20001"))6、添加arbiter节点：rs.addArb("10.0.1.123:20001") 7、添加延时备份机器：rs.add({_id:4,host:"10.0.1.124:20001",priority:0,slaveDelay:3600});8、当出现这个错误时：replSet error RS102 too stale to catch up，我们可以db.printReplicationInfo() 查看主库、从库的oplog信息；以上为我切换过程中用到的大部分命令，主要还是replica set管理工具，如果能掌握，那么升级、扩容、主库切换都能快速进行！

本文出自 “成功来源于分享” 博客，请务必保留此出处http://linuxchina.blog.51cto.com/938835/1209673