mongodb副本集的原理及命令

1.mongodb副本集的定义

副本集（Replica Set）是一组MongoDB实例组成的集群，由一个主（Primary）服务器和多个备份（Secondary）服务器构成。通过Replication，将数据的更新由Primary推送到其他实例上，在一定的延迟之后，每个MongoDB实例维护相同的数据集副本。通过维护冗余的数据库副本，能够实现数据的异地备份，读写分离和自动故障转移

打魔兽世界总说打副本，其实这两个概念差不多一个意思。游戏里的副本是指玩家集中在高峰时间去一个场景打怪，会出现玩家暴多怪物少的情况，游戏开发商为了保证玩家的体验度，就为每一批玩家单独开放一个同样的空间同样的数量的怪物，这一个复制的场景就是一个副本，不管有多少个玩家各自在各自的副本里玩不会互相影响。 mongoDB的副本也是这个，主从模式其实就是一个单副本的应用，没有很好的扩展性和容错性。而副本集具有多个副本保证了容错性，就算一个副本挂掉了还有很多副本存在，并且解决了上面第一个问题“主节点挂掉了，整个集群内会自动切换”。难怪mongoDB官方推荐使用这种模式。我们来看看mongoDB副本集的架构图

由图可以看到客户端连接到整个副本集，不关心具体哪一台机器是否挂掉。主服务器负责整个副本集的读写，副本集定期同步数据备份，一但主节点挂掉，副本节点就会选举一个新的主服务器，这一切对于应用服务器不需要关心。我们看一下主服务器挂掉后的架构：

 

 

首先从概念上说一下MongoDB副本集和主从复制的区别。其实副本集（Replica Set）是主从复制的高级形式。高级在哪里呢？主动复制实现了数据备份+读扩展，但是master一旦down掉，需要手动启动slave。副本集在此基础上实现了备份自动重启的功能，也就是某一台slave会挺身而出，担当起master的职责。所以有三个角色，master（Primary），slave（Secondary），还有仲裁服务器。

2.使用场景

• 数据冗余，用做故障恢复使用，当发生硬件故障或者其它原因造成的宕机时，可以使用副本进行恢复。
• 读写分离，读的请求分流到副本上，减轻主节点的读压力

副本集特征：

• N 个节点的集群
• 任何节点可作为主节点
• 所有写入操作都在主节点上
• 自动故障转移
• 自动恢复

3.副本集角色

1. 主节点（Primary）
   接收所有的写请求，然后把修改同步到所有Secondary。一个Replica Set只能有一个Primary节点，当Primary挂掉后，其他Secondary或者Arbiter节点会重新选举出来一个主节点。
   默认读请求也是发到Primary节点处理的，可以通过修改客户端连接配置以支持读取Secondary节点。

2. 副本节点（Secondary）
   与主节点保持同样的数据集。当主节点挂掉的时候，参与选主。

3. 仲裁者（Arbiter）
   不保有数据，不参与选主，只进行选主投票。使用Arbiter可以减轻数据存储的硬件需求，Arbiter几乎没什么大的硬件资源需求，但重要的一点是，在生产环境下它和其他数据节点不要部署在同一台机器

4.副本集的一些操作

rs.status()   //查看成员的运行状态等信息

rs.config()    //查看配置信息

rs.slaveOk()  //允许在SECONDARY节点上进行查询操作，默认从节点不具有查询功能

rs.isMaster()  //查询该节点是否是主节点

rs.add({})   //添加新的节点到该副本集中

rs.remove()   //从副本集中删除节点

5.副本集中数据同步过程：Primary节点写入数据，Secondary通过读取Primary的oplog得到复制信息，开始复制数据并且将复制信息写入到自己的oplog。如果某个操作失败，则备份节点停止从当前数据源复制数据。如果某个备份节点由于某些原因挂掉了，当重新启动后，就会自动从oplog的最后一个操作开始同步，同步完成后，将信息写入自己的oplog，由于复制操作是先复制数据，复制完成后再写入oplog，有可能相同的操作会同步两份，不过MongoDB在设计之初就考虑到这个问题，将oplog的同一个操作执行多次，与执行一次的效果是一样的。简单的说就是：

当Primary节点完成数据操作后，Secondary会做出一系列的动作保证数据的同步：
1：检查自己local库的oplog.rs集合找出最近的时间戳。
2：检查Primary节点local库oplog.rs集合，找出大于此时间戳的记录。
3：将找到的记录插入到自己的oplog.rs集合中，并执行这些操作。

       副本集的同步和主从同步一样，都是异步同步的过程，不同的是副本集有个自动故障转移的功能。其原理是：slave端从primary端获取日志，然后在自己身上完全顺序的执行日志所记录的各种操作（该日志是不记录查询操作的），这个日志就是local数据 库中的oplog.rs表，默认在64位机器上这个表是比较大的，占磁盘大小的5%，oplog.rs的大小可以在启动参数中设 定：--oplogSize 1000,单位是M。

      注意：在副本集的环境中，要是所有的Secondary都宕机了，只剩下Primary。最后Primary会变成Secondary，不能提供服务。