MongoDB权威指南-第9章

MongoDB权威指南
复制
9.1-复制简介
在MongoDB中,创建一个副本集之后就可以使用复制功能了.副本集是一组服务器,其中一个主服务器,用于处理客户端请求;还有多个备份服务器,用于保存主服务器的数据副本.如果主服务器崩溃了,备份服务器会自动将其中一个成员升级为新的主服务器.
9.2-建立副本集
mongo –nodb
创建一个副本集:replicaSet = new ReplSetTest({“nodes”:3})
replicaSet.startSet()
replicaSet.initiate()
连接到主节点上执行isMaster
设置”从备份节点读取数据没有问题”标识 conn2.setSlaveOk()
slaveOk是对连接设置的,不是对数据库secdondaryDB设置的
不能对备份节点执行写操作.备份节点只能通过复制功能写入数据,不接收客户端的写入请求
关键
客户端在单台服务器上可以执行的请求,都可以发送到主节点执行(读/写、执行命令,创建索引等)
客户端不能在备份节点执行写操作
默认情况下,客户端不能从备份节点读取数据.在备份节点显示执行setSlaveOk后,客户端就可以从备份节点读取数据了
9.3-配置副本集
mongod –replSet spock -f mongod.conf –fork
config={“_id”:”spork”,”members”:[{“_id”:0,”host”:”server1:27017”},{},{}]}
rs.initiate(config)
可惜无法将单机服务器转换为副本集,除非停机重启并进行初始化.
9.3.1-rs辅助函数
rs是一个全局变量
db.runCommand(“replSetInitiate”:config)
9.4-修改副本集配置
rs.add(“server-4:27017”)
rs.remove(“server-4:27017”)
rs.config来查看配置是否成功
9.5-设计副本集
简介
“大多数”:副本中一半以上的成员
5个成员的副本集,其中3个不可用,剩余2个已经无法达到副本集”大多数”的要求.所以它们就无法选举主节点,就会从主节点上退位.几秒钟后,这个副本集会包含2个备份节点和3个不可达成员.
2种推荐配置
将”大多数”成员放在一个数据中心
两个数据中心各自放置数量相等的成员,在第三个地方放置一个用于决定胜负的副本集成员
手工解决冲突或让系统任选一个作为”赢家”都不容易实现,因为无法确保写入的数据不会诶其他节点修改
选举机制
希望成为主节点的成员(候选人)必须使用复制将自己的数据更新为最新,副本集中的其他成员会对此进行检查
每个成员都只能要求自己被选举为主节点
仲裁者的唯一作用就是参与选举.仲裁者并不保存数据,也不会为客户端提供服务;它只是为了辅助有两个成员的副本集能够满足’大多数’的条件
如果可能,应将仲裁者放在单独的故障域(failure domain)中,与其他成员分开
启动仲裁者
rs.addArb(“server-5:27017”)
rs.add({“_id”:4,host:”server-5:27017”,”arbiterOnly”:true})
成员一旦以仲裁者的身份被添加到副本集中,它就永远只是仲裁者;无法将仲裁者重新配置为非仲裁者,反之亦然
9.6-成员配置选项
9.6.1-选举仲裁者
1-仲裁者的目的应该是避免平票
2-如有可能尽可能在副本集中使用奇数个数据成员,而不要使用仲裁者
9.6.2-优先级
优先级为0的成员永远不可能成为主节点
设置优先级并不会导致副本集中选不出主节点,也不会使数据不够新的成员成为主节点
优先级的值只会影响副本集成员间相对优先级的大小关系
9.6.3-隐藏成员
客户端不会向隐藏成员发送请求,隐藏成员也不会作为复制源
只有优先级为0的成员才能被隐藏(不能隐藏主节点)
9.6.4-延迟备份节点
使用slaveDelay设置一个延迟备份点
slaveDelay要求成员优先级为0.如果你的应用会将请求路由到备份节点,应该将延迟备份节点隐藏掉,以免强求被路由到延迟备份节点
9.6.5-创建索引
buildIndexes:false
复制
9.1-复制简介
在MongoDB中,创建一个副本集之后就可以使用复制功能了.副本集是一组服务器,其中一个主服务器,用于处理客户端请求;还有多个备份服务器,用于保存主服务器的数据副本.如果主服务器崩溃了,备份服务器会自动将其中一个成员升级为新的主服务器.
9.2-建立副本集
mongo –nodb
创建一个副本集:replicaSet = new ReplSetTest({“nodes”:3})
replicaSet.startSet()
replicaSet.initiate()
连接到主节点上执行isMaster
设置”从备份节点读取数据没有问题”标识 conn2.setSlaveOk()
slaveOk是对连接设置的,不是对数据库secdondaryDB设置的
不能对备份节点执行写操作.备份节点只能通过复制功能写入数据,不接收客户端的写入请求
关键
客户端在单台服务器上可以执行的请求,都可以发送到主节点执行(读/写、执行命令,创建索引等)
客户端不能在备份节点执行写操作
默认情况下,客户端不能从备份节点读取数据.在备份节点显示执行setSlaveOk后,客户端就可以从备份节点读取数据了
9.3-配置副本集
mongod –replSet spock -f mongod.conf –fork
config={“_id”:”spork”,”members”:[{“_id”:0,”host”:”server1:27017”},{},{}]}
rs.initiate(config)
可惜无法将单机服务器转换为副本集,除非停机重启并进行初始化.
9.3.1-rs辅助函数
rs是一个全局变量
db.runCommand(“replSetInitiate”:config)
9.4-修改副本集配置
rs.add(“server-4:27017”)
rs.remove(“server-4:27017”)
rs.config来查看配置是否成功
9.5-设计副本集
简介
“大多数”:副本中一半以上的成员
5个成员的副本集,其中3个不可用,剩余2个已经无法达到副本集”大多数”的要求.所以它们就无法选举主节点,就会从主节点上退位.几秒钟后,这个副本集会包含2个备份节点和3个不可达成员.
2种推荐配置
将”大多数”成员放在一个数据中心
两个数据中心各自放置数量相等的成员,在第三个地方放置一个用于决定胜负的副本集成员
手工解决冲突或让系统任选一个作为”赢家”都不容易实现,因为无法确保写入的数据不会诶其他节点修改
选举机制
希望成为主节点的成员(候选人)必须使用复制将自己的数据更新为最新,副本集中的其他成员会对此进行检查
每个成员都只能要求自己被选举为主节点
仲裁者的唯一作用就是参与选举.仲裁者并不保存数据,也不会为客户端提供服务;它只是为了辅助有两个成员的副本集能够满足’大多数’的条件
如果可能,应将仲裁者放在单独的故障域(failure domain)中,与其他成员分开
启动仲裁者
rs.addArb(“server-5:27017”)
rs.add({“_id”:4,host:”server-5:27017”,”arbiterOnly”:true})
成员一旦以仲裁者的身份被添加到副本集中,它就永远只是仲裁者;无法将仲裁者重新配置为非仲裁者,反之亦然
9.6-成员配置选项
9.6.1-选举仲裁者
1-仲裁者的目的应该是避免平票
2-如有可能尽可能在副本集中使用奇数个数据成员,而不要使用仲裁者
9.6.2-优先级
优先级为0的成员永远不可能成为主节点
设置优先级并不会导致副本集中选不出主节点,也不会使数据不够新的成员成为主节点
优先级的值只会影响副本集成员间相对优先级的大小关系
9.6.3-隐藏成员
客户端不会向隐藏成员发送请求,隐藏成员也不会作为复制源
只有优先级为0的成员才能被隐藏(不能隐藏主节点)
9.6.4-延迟备份节点
使用slaveDelay设置一个延迟备份点
slaveDelay要求成员优先级为0.如果你的应用会将请求路由到备份节点,应该将延迟备份节点隐藏掉,以免强求被路由到延迟备份节点
9.6.5-创建索引
buildIndexes:false