Mongodb副本集配置
副本集就是有自动故障恢复功能的主从集群。主从集群和副本集最为明显的区别就是副本集没有固定的主节点。
可以把副本集当做一个集群，整个集群会选出一个主节点，当其不能正常工作时则会激活其它节点。
系统：
ＣentOS 5.6 x86_64
mongo版本：mongodb-linux-x86_64-2.0.6.tgz
Server1 10.0.1.121:20001
server2 10.0.1.212:20001
Arbiter 10.0.1.212:20002
目录规划：
数据目录和日志单分出来
Server1:
/mongodb
/mlogs
应用程序日志统计放到/usr/local/mongo
Server2:
/mongodb
/mlogs
/arbiter
应用程序日志统计放到/usr/local/mongo
部署：
1.防火墙开启20001端口，关闭selinux
2.分别在两台机器上安装mongo服务
tar xf mongodb-linux-x86_64-2.0.6.tgz -C /usr/local/mongo
3.创建key文件
Server1:
mkdir /etc/keys
echo "test123456" > r0
Server2:
mkdir /etc/keys
echo "test123456" > r1
Arbiter:
echo "test123456" > r2
chmod 600 r0 r1 r2
4.分别启动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.local
Server2:
/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文件大小
配置的oplog文件大小
log length start to end:
oplog日志的启用时间段
oplog日志的启用时间段
oplog first event time:
产生时间 oplog last
产生时间 oplog last
event time:
最后一个事务日志的产生时间
最后一个事务日志的产生时间
now:
现在的时间
现在的时间
注意：oplog不记录查询操作，oplog存储在固定集合里面，所以它们会自动替换旧的操作。
我们在启动服务器的时候可以用--oplogSize指定这个大小（MB）
查看slave的同步状态
rs1:PRIMARY> db.printSlaveReplicationInfo()
source: 从库的IP及端口
syncedTo: 目前的同步情况，延迟了多久等信息
主从配置信息
主从配置信息
在local库中还有一个集合用于记录主从配置信息system.replset
rs1:PRIMARY> db.system.replset.find()
管理维护Replica Sets
读写分离、
从库要是进行查询，分担主库的大量的查询请求
1)先向主库中插入一条测试数据
2)在从库进行查询等操作
3)让从库可以读，分担主库的压力
执行db.getMongo().setSlaveOk()，我们就可查询从库了
故障转移
副本集比传统的Master-Slave 有改进的地方就是它可以进
行故障的自动转移，如果我们停掉复制集中的一个成员，那
么剩余成员会再自动选举出一个成员，做为主库。
1)杀掉Server1 20001 端口的MongoDB
2)查看副本集状态 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管理工具，如果能掌握，那么升级、扩容、主库切换都能快速进行！