MongoDB复制ppt.pptVIP

Master-Slave(主从)模式 工作方式： 一个主节点写入 多个从节点复制数据，并承担读任务 优点： 读写分离，提高负载能力 数据备份 搭建容易 缺点: 主节点宕机，系统不可用 如何搭建MongoDB的主从？ 配置选项：?? ?--master??以主服务器方式启动?? ? --slave???以从服务器方式启动???? --autoresync：自动重新sync，因为该操作会copy 主服务器上的所有document，比较耗时，在10分钟内最多只会进行一次。?? ? --oplogSize：指定master上用于存放更改的数据量，如果不指定，在32位机上最少为50M，在64位机上最少为 1G，最大为磁盘空间的5%。?? ? --source??主服务器地址（与--slave组合使用）?? ? --only????仅限于同步指定数据库 ?? ? --slavedelay??同步延时 主节点 bin/mongod --master --dbpath /data/db1 从节点 bin/mongod --slave –source IP --dbpath /data/db2 一般数据库都会用到这种最通用的模式——主从模式。这种方式简单灵活，可用于备份、故障恢复，读扩展。为了平衡负载，一般通过读写分离模式，即主库写、从库读。 读写分离的特点：(1)、将密集的读取操作分流到从节点上，降低主节点的负载。(2)、默认情况下，从节点是不允许处理客户端请求的，需要使用--slaveOkay打开。(3)、不适用于实时性要求非常高的应用。 同志们这里要实际操作啊！ Replica pairs模式 以这种方式启动后，数据库会自动协商谁是master谁是slave。一旦一个数据库服务器断电，另一个会自动接管，并从那一刻起起为master。如果另一个将来也出错了，那么master状态将会转回给第一个服务器。 这种模式下的两台机器只能满足最终一致性。当replica pair中的一台机器完全挂掉时，需要用一台新的来代替。如(n1, n2)中的n2挂掉，这时用n3来代替n2。步骤如下：?? ?? 1. 告诉n1用n3来代替n2?? ?? 2. 重启n1让它同n3对话 ?? ?? 3. 启动n3 ★在n3的数据没有同步到n1前n3还不能做master，这个过程长短由数据量的多少决定。 配置选项：?? ?? mongod --pairwith remoteserver --arbiter arbiterserver ?? ?? --pairwith: remoteserver是pair里的另一个server?? ?? --arbiter:? arbiterserver是一个起仲裁作用的Mongo数据库，用来协商pair中哪一个是master。arbiter运行在第三个机器上，利用“平分决胜制”决定在pair中的两台机器不能联系上对方时让哪一个做master，一般是能同arbiter通话的那台机器做master。如果不加--arbiter选项，出现网络问题时两台机器都作为master。 Replica Sets模式 在Mongodb中，提供了一种优于主从模式的集群复制。最理想的模式是，节点之间不分特定的主从。任何一个节点都可以是主节点primary，而其他节点都是secondary，甚至可以通过投票方式选出主节点。 Replica Sets模式具有多个副本保证了容错性，就算一个副本挂掉了还有很多副本存在，并且解决了问题“主节点挂掉了，整个集群内会自动切换”。 优点： 数据冗余 自动恢复 分离读压力 维护简单 灾难恢复 当我们的副本节点增多时，主节点的复制压力会加大有什么办法解决吗？mongodb早就有了相应的解决方案。 其中的仲裁节点不存储数据，只是负责故障转移的群体投票，这样就少了数据复制的压力。 自动故障切换 制集通过故障自动切换来实现高可用性，当主节点出现故障时，从节点可以通过选举成为主节点，而这个过程在大多数当情况下是自动进行的，不需要手动干预。在某些情况下，故障自动切换需要数据回滚。 包括两大过程：选举 和 回滚 影响选举的因素 oplog 副本集同步 前面说过oplog保存了数据的操作记录，secondary复制oplog并把里面的操作在secondary执行一遍。但是oplog也是mongodb的一个集合，保存在local.oplog.rs里，但是这个oplog是一个capped?collection也就