【Python基础】mongodb副本集原理是什么_Python

2条回答

aijingda

2楼 · 2021-01-20 16:24

mongodb副本集即客户端连接到整个副本集，不关心具体哪一台机器是否挂掉。主服务器负责整个副本集的读写，副本集定期同步数据备份，一旦主节点挂掉，副本节点就会选举一个新的主服务器，这一切对于应用服务器不需要关心

副本集中的副本节点在主节点挂掉后通过心跳机制检测到后，就会在集群内发起主节点的选举机制，自动选举一位新的主服务器

选举还有个前提条件，参与选举的节点数量必须大于副本集总节点数量的一半，如果已经小于一半了所有节点保持只读状态。因此，官方推荐我们的副本集机器数量至少为3个：[一个主节点，两个副本节点] 也可以为[一个主节点,一个副本节点,一个仲裁节点]

其中有一个仲裁节点，即当参与选举的节点无法选出主节点时仲裁节点充当仲裁的作用。仲裁节点不存储数据，只是仲裁。所以，我们的副本集可以设置为：1主+1从+1仲裁

我的网名不再改

3楼 · 2021-01-22 12:48

1.mongodb副本集的定义

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

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

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

mongodb故障转移

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

2.使用场景

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

副本集特征：

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

3.副本集角色

主节点（Primary）
接收所有的写请求，然后把修改同步到所有Secondary。一个Replica Set只能有一个Primary节点，当Primary挂掉后，其他Secondary或者Arbiter节点会重新选举出来一个主节点。
默认读请求也是发到Primary节点处理的，可以通过修改客户端连接配置以支持读取Secondary节点。
副本节点（Secondary）
与主节点保持同样的数据集。当主节点挂掉的时候，参与选主。
仲裁者（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，不能提供服务。