MongoDB---复制简析(二)
在备份节点查询,会出现
error: { "$err" : "not master and slaveok=false", "code" : 13435 }错误.
执行如下语句:
db.getMongo().setSlaveOk()
6.副本集中的节点
任何时间,集群中只有一个活跃节点,其他的都是备份节点.活跃节点实际上是活跃服务器,指定的活跃节点可以随时间而改变.
有几种不同类型的节点可以存在与副本集中
standard 标准节点
这是常规节点,它存储一份完整的数据副本,参与选举投票有可能成为活跃节点
passive 被动结点
存储了完整的数据副本,参与投票,不能成为活跃节点
arbiter 仲裁者
仲裁者只能参与投票,不接收复制的数据,也不能成为活跃节点.
标准节点和被动节点之间的区别仅仅是数量的差别,每个参与节点(非仲裁)有优先权.
优先权按照优先值从大到小.
在节点配置中修改priority键,来配置标准节点或者被动节点.
>members.push({"_id":3,"host":"127.0.0.1:10002","priority":40})
默认优先级为1,可以是0-1000(含)
"arbiterOnly"键可以指定仲裁节点
>members.push({"_id":4,"host":"127.0.0.1:10003","arbiterOnly":true})
备份节点会从活跃节点抽取oplog,并执行操作,就像活跃备份
系统中的备份服务器一样.活跃节点也会写操作
到自己的本地oplog.oplog中的操作包含严格递增的序号,这个序号来判定数据的时效性.
7.故障切换和活跃节点选举
如果活跃节点出现故障,其余节点会选一个新的活跃节点.选举过程可以由任何非活跃节点发起,新的活跃节点由
副本集中的大多数选举产生.仲裁节点也参与选举,避免出现僵局.新的活跃节点将是优先级最高的节点,优先级相同
这数据较新的节点获胜.
不论活跃节点何时变化,新的活跃节点的数据就被假定为系统的最新数据.对其他几点(原来的活跃节点)的操作都会
回滚,即便是之前的活跃节点已经恢复工作了.为了完成回滚,所有节点连接新的活跃节点后重新同步.这些节点会查看
自己的oplog,找出自重活跃节点没有的操作,然后向活跃节点请求这些操作影响的文档最新副本.正在执行重新同步的
节点被视为恢复中,在完成这个过程之前不能成为活跃节点的候选者.
8.在从服务器上执行操作
从节点的主要作用是作为故障恢复机制,以防主节点数据丢失或停止服务.
从节点可以用作备份数据源,可以用来扩展读取性能,或者进行数据处理.
9.读扩展
用MongoDB扩展读取的一种方式是将查询放在从节点上.这样,主节点的负载就减轻了.一般来说,当负载是读取密集型 www.2cto.com
时,这是很好的方案.要是谢密集型,则要用分片来进行扩展.
使用从节点来扩展MongoDB的读取有个要点,就是数据复制并不同步,也就是说在主节点插入和更新数据后,
有片刻从节点的数据不是最新的.在考虑用查询从节点完成请求时,应注意.
扩展读取本身很简单,像往常一样设置主从复制,连接从服务器处理请求.唯一的技巧是有个特殊的查询选项,告诉
从服务器是否可以处理请求(默认是不可以的).这个选项是slaveOkay,所有的MongoDB驱动程序都提供了
一种机制来设置它.有些驱动程序还提供工具使得请求分布到从节点的过程自动化,但这个过程随驱动程序的
不同而不同.
10.用从节点做数据处理
从节点的另外一个用途是作为一种机制来减轻密集型处理的负载,或作为聚合,避免影响主节点的性能.用--mster
参数启动一个普通的从节点.同时使用--slave和--master有点矛盾,这意味着如果能对从节点进行写入,像往常
一样查询,就把它作为一个普通的MongoDB主节点就行了,向从节点插入数据不会同步到主节点中.
从节点还是会不断的从真正的主节点复制数据.
这样,就可以对从节点执行阻塞操作也不影响主节点的性能.
用这种技术的时候,一定要确保不能对正在复制主节点数据的从节点上的数据库进行写入.从节点不能恢复这些操作,
就不能映射主节点.
11.工作原理
MongoDB的复制至少需要两个服务器或节点.其中一个是主节点,负责处理客户端请求,其他都是从节点
负责映射主节点的数据.主节点记录在其上执行的所有操作.从节点定期轮训主节点获得这些操作,然后对自己的
数据副本执行这些操作.由于和主节点执行了相同的操作,从节点就能保持与主节点的数据同步.
oplog
主节点的操作记录成为oplog(operation log).oplog存储在一个特殊的数据库中,叫做local.
oplog就在其中的oplpg.$main集合里面.oplpg中的每个文档都代表主节点上执行的一个操作.
> db.oplog.$main.findOne()
{
"ts" : {
"t" : 1342705298000,
"i" : 11
},
"op" : "n",
"ns" : "",
"o" : {
}
}
"ts"
操作的时间戳.时间戳是一种内部类型,用于跟踪操作执行的时间,由4个字节的时间戳和4个自己的递增计数器构成 www.2cto.com
"op"
操作类型,只有一个字节.("i"代表插入)
"ns"
执行操作的命名空间(集合名)
"o"
进一步执行要执行操作的文档,对插入来说,就是要插入的文档.
oplog只记录改变数据库状态的操作.如查询不会存储在oplog中,这是因为oplog只是作为从节点与
主节点保持数据同步的机制.
存储在oplog中的操作也不是完全和主节点的操作已于一样的.这些操作在存储之前先要做等幂变换,也就是说
这些操作可以在服务器端多次执行,只要顺序是对的,就不会有问题.如使用"$inc"执行的增加更新操作,
会变成"$set"操作.
oplog存储在固定集合中.由于新操作也会存储在oplog中,他们会自动替换旧的操作.这样能保证oplog不能
超过预先设定的大小.启动服务器时可以用--oplogsize指定这个大小,单位是MB.默认情况下,64位的实例将会使用
oplog 5%的可用空间.这个空间将在local数据库中分配,并在服务器启动时预先分配.
12.同步
从节点第一次启动时,会对主节点数据进行完整的同步.从节点复制主节点上的每个文档,很耗资源.同步完成后,
从节点开始查询主节点的oplog并执行这些操作,以保证数据是最新的.
如果从节点的操作和主节点的相差很远,从节点就跟不上同步了.跟不上同步的从节点无法一直追赶主节点.因为
主节点oplog的所有操作太新了.从节点发生了宕机或着疲于应付读取时会出现这