什么是 MongoDB 的副本集?
副本集由一个主节点(Primary
)和多个从节点(Secondary
)组成。
- 主节点负责处理所有的写操作,并将写操作的结果复制到从节点上。
- 从节点则负责复制主节点的数据,并可以接收读请求。
副本集的主要目标是提供数据的冗余备份和故障恢复能力。如果主节点发生故障,副本集会自动选举一个新的主节点来接管写操作,并继续提供服务。这种自动故障转移机制确保了系统的高可用性和持续可用性。
副本集的各种角色
角色 | 说明 |
---|---|
Primary | 主服务器,只有一组,处理客户端的请求,一般是读写 |
Secondary | 从服务器,有多组,保存主服务器的数据副本,主服务器出问题时其中一个从服务器可提升为新主服务器,可提供只读服务 |
Hidden | 一般只用于备份节点,不处理客户端的读请求 |
Secondary-Only | 不能成为 Primary 节点,只能作为 Secondary 副本节点,防止一些性能不高的节点成为主节点 |
Delayed | slaveDelay 来设置,为不处理客户端请求,一般需要隐藏 |
Non-Voting | 没有选举权的 Secondary 节点,纯粹的备份数据节点 |
Arbiter | 仲裁节点,不存数据,只参与选举,可用可不用 |
什么是分片?
MongoDB 的分片(sharding
)是一种用于处理大规模数据集的数据分布和负载均衡技术。它允许将数据分散存储在多个物理或虚拟服务器上,以提高系统的可扩展性和性能。
在 MongoDB 分片架构中,数据被划分为多个分片(shard
),每个分片都是一个独立的 MongoDB 实例或集群。每个分片只存储整个数据集的一部分,这样可以将数据分布在多个节点上,从而实现数据的水平扩展。
MongoDB 分片适用于如下几个场景:
- 单个服务器无法承受压力时,压力包括负载、频繁写、吞吐量等;
- 服务器磁盘空间不足时;
- 增加可用内存大小,以更多的数据在内存中访问。
MongoDB 驱动的 5 种读取策略
策略 | 说明 |
---|---|
primary | 默认参数,只从主节点上进行读取操作 |
primaryPreferred | 大部分从主节点上读取数据,只有主节点不可用时从 secondary 节点读取数据 |
secondary | 只从 secondary 节点上进行读取操作,存在的问题是 secondary 节点的数据会比 primary 节点数据 “旧” |
secondaryPreferred | 优先从 secondary 节点进行读取操作,`secondary 节点不可用时从主节点读取数据 |
nearest | 不管是主节点、secondary 节点,从网络延迟最低的节点上读取数据 |
MongoDB 分片集群的 3 个组件
组件名 | 作用 |
---|---|
mongos | 数据库集群请求的入口,起到路由作用,它负责把对应的数据请求请求转发到对应的 shard 服务器上。生产环境中需要多个 mongos |
config server | 保存集群和分片的元数据,mongos 启动时会加载配置服务器上的配置信息,以后如果配置服务器信息变化会通知到所有的 mongos 更新自己的状态。生产环境需要多个配置服务器。也需要定期备份。 |
shard server | 实际存储数据的分片。生产环境要求是副本集。 |
这里要注意 mongos
提供的是客户端与 MongoDB 分片集群的路由功能,这里分片集群包含了分片的 collection
和非分片的 collection
。如下展示了通过路由访问分片的 collection
和非分片的 collection
:
其他补充概念
同步
初始化同步,从副本集中其他节点全量同步一次,触发条件如下:
Secondary
节点首次加入时;Secondary
节点落后oplog
大小以上的数据时;- 回滚失败时
保持同步,初始化同步之后的增量同步!
注意:同步源并非是
Primary
节点,MongoDB
根据Ping
时间长短来选择同步源的,也即会选择一个离自己比较近的而且数据比自己新的成员
心跳
- 心跳是用来检测
Primary
节点是谁、哪个节点可以作为同步源等的 - 每个节点每 2 秒会向其他节点发送心跳请求,根据其结果来维护自己的状态视图
Primary
节点也是通过心跳确认自己是否满足 “大多数” 的选举条件,如果不满足,它就会退位变成Secondary
节点
回滚
Primary
执行了写请求之后宕机,Secondary
节点还没来得及复制本次的写操作,也就意味着新选举的Primary
上没有这个写操作。- 这时候原
Primary
恢复并成为Secondary
时,需要回滚这个写操作以能够重新进行同步。回滚数据量大于300 MB
或者需要回滚的时间超过30分钟,回滚就会失败,必须重新全量同步。