1、概念
MongoDB复制集的主要意义在于实现服务高可用,类似于Redis中的哨兵模式
2、功能
1. 数据写入主节点时将数据复制到另一个副本节点上
2. 主节点发生故障时自动选举出一个新的替代节点
在实现高可用的同时,复制集实现了其他几个作用
数据分发:将数据从一个区域复制到另一个区域,减少另一个区域的读延迟
读写分离:不同类型的压力分别在不同的节点上执行
异地容灾:在数据中心故障时快速切换到异地
1、典型复制集结构
一个典型的复制集由三个或三个以上具有投票权的节点组成
其中一个主节点(Primary):接收写入操作,读操作和选举时投票
两个或多个从节点(Secondary):复制主节点上的新数据和选举时投票
2、数据是如何复制的?
当一个修改操作,无论是插入,更新或删除,到达主节点时,它对数据的操作将被记录下来(经过一些必要的转换)。这些记录称为oplog
从节点通过从主节点上不断获取新进入主节点的oplog,并在自己的数据上回放,以此保持跟主节点的数据一致。
1、什么是oplog
- MongoDB oplog 是 Local 库下的一个集合,用来保存写操作所产生的增量日志(类似于 MySQL 中 的 Binlog)。
- 它是一个 Capped Collection(固定集合),即超出配置的最大值后,会自动删除最老的历史数据,MongoDB 针对 oplog 的删除有特殊优化,以提升删除效率。
- 主节点产生新的 oplog Entry,从节点通过复制 oplog 并应用来保持和主节点的状态一致;
2、查看oplog
use local
db.oplog.rs.find().sort({$natural:-1}).pretty()
local.system.replset:用来记录当前复制集的成员。
local.startup_log:用来记录本地数据库的启动日志信息。
local.replset.minvalid:用来记录复制集的跟踪信息,如初始化同步需要的字段。
- ts: 操作时间,当前timestamp + 计数器,计数器每秒都被重置
- v:oplog版本信息
- op:操作类型:
- i:插⼊操作
- u:更新操作
- d:删除操作
- c:执⾏命令(如createDatabase,dropDatabase)
- n:空操作,特殊⽤途
- ns:操作针对的集合
- o:操作内容
- o2:操作查询条件,仅update操作包含该字段
ts字段描述了oplog产生的时间戳,可称之为optime。optime是备节点实现增量日志同步的关键,它保证了oplog是节点有序的,其由两部分组成:
- 当前的系统时间,即UNIX时间至现在的秒数,32位。
- 整数计时器,不同时间值会将计数器进行重置,32位。
optime属于BSON的Timestamp类型,这个类型一般在MongoDB内部使用。既然oplog保证了节点级有序,那么备节点便可以通过轮询的方式进行拉取,这里会用到可持续追踪的游标(tailable cursor)技术。
3、oplog集合的大小
oplog集合的大小可以通过参数replication.oplogSizeMB设置,对于64位系统来说,oplog的默认值为:
plogSizeMB = min(磁盘可用空间*5%,50GB)
对于大多数业务场景来说,很难在一开始评估出一个合适的oplogSize,所幸的是MongoDB在4.0版本之后提供了replSetResizeOplog命令,可以实现动态修改oplogSize而不需要重启服务器。
# 将复制集成员的oplog大小修改为60g 指定大小必须大于990M
db.adminCommand({replSetResizeOplog: 1, size: 60000})# 查看oplog大小
use local
db.oplog.rs.stats().maxSize
4、幂等性
每一条oplog记录都描述了一次数据的原子性变更,对于oplog来说,必须保证是幂等性的。
也就是说,对于同一个oplog,无论进行多少次回放操作,数据的最终状态都会保持不变。
某文档x字段当前值为100,用户向Primary发送一条{$inc: {x: 1}},记录oplog时会转化为一条{$set: {x: 101}的操作,才能保证幂等性。
5、oplog的写入被放大,导致同步追不上——大数组更新
当数组非常大时,对数组的一个小更新,可能就需要把整个数组的内容记录到oplog里,我遇到一个实际的生产环境案例,用户的文档内包含一个很大的数组字段,1000个元素总大小在64KB左右,这个数组里的元素按时间反序存储,新插入的元素会放到数组的最前面($position: 0),然后保留数组的前1000个元素($slice: 1000)。
上述场景导致,Primary上的每次往数组里插入一个新元素(请求大概几百字节),oplog里就要记录整个数组的内容,Secondary同步时会拉取oplog并重放,Primary到Secondary同步oplog的流量是客户端到Primary网络流量的上百倍,导致主备间网卡流量跑满,而且由于oplog的量太大,旧的内容很快被删除掉,最终导致Secondary追不上,转换为RECOVERING状态。
在文档里使用数组时,一定得注意上述问题,避免数组的更新导致同步开销被无限放大的问题。使用数组时,尽量注意:
- 数组的元素个数不要太多,总的大小也不要太大
- 尽量避免对数组进行更新操作
- 如果一定要更新,尽量只在尾部插入元素,复杂的逻辑可以考虑在业务层面上来支持
3、通过选举完成故障恢复
具有投票权的节点之间两两互相发送心跳;
当5次心跳未收到时判断为节点失联
如果失联的是主机点,从节点会发起选举,选出新的主节点
如果失联的是从节点则不会产生新的选举
选举基于RAFT一致性算法实现,选举成功的必要条件是大多数投票节点存活
复制集中最多可以有50个节点,但具有投票权的节点最多7个
4、影响选举的因素
整个集群必须有大多数节点存活,被选举为主节点的节点必须:
1.能够与多数节点建立连接
2.具有较新的oplog
3.具有较高的优先级(如果有配置)
5、复制集节点有以下的选配项
(1)是否具有投票权(v 参数)
有则参与投票
(2)优先级(priority参数)
优先级越高的节点越优先成为主节点。优先级为0的节点无法成为主节点,默认值为1。
(3)隐藏(hidden参数)
复制数据,但对应用不可见。隐藏节点可以具有投票权,但优先级必须为0
(4)延迟(slaveDelay参数)
复制 n 秒之前的数据,保持与主节点的时间差,有点备份的意思
从节点不建立索引
6、复制集注意事项
硬件:
因为正常的复制集节点都有可能成为主节点,它们的地位是一样的,因此硬件配置上必须一致
为了保证节点不会同时宕机,各节点的硬件必须具有独立性。
软件:
复制集各节点软件版本必须一致,以避免出现不可预知的问题
增加节点不会增加系统写性能
3、分片集群
每个分片本身就是一个复制集
将数据水平拆分到不同的服务器上
原因:
- 数据量突破单机瓶颈,数据量大,恢复很慢,不利于数据管理
- 并发量突破单机性能瓶颈
1、分片集群由一下几部分组成
2、分片集群角色
1、路由节点
mongos提供集群单一入口,转发应用端请求,选择合适的数据节点进行读写,合并多个数据节点的返回。
无状态,建议 mongos节点集群部署以提供高可用性。客户请求应发给mongos,而不是分片服务器,当查询包含分片键时,mongos将查询发送到指定分片,否则,mongos将查询发送到所有分片,并汇总所有查询结果。
2、配置节点
就是普通的mongod进程, 建议以复制集部署,提供高可用。
提供集群元数据存储分片数据分布的数据。主节点故障时,配置服务器进入只读模式,只读模式下,数据段分裂和集群平衡都不可执行。整个复制集故障时,分片集群不可用。
3、数据节点
以复制集为单位,横向扩展最大1024分片,分片之间数据不重复,所有数据在一起才可以完整工作。
3、分片键
分片键是 MongoDB 中用于将数据分割成块(Chunks)并分布到分片集群(Sharded Cluster)不同分片(Shard)上的一个或多个字段。选择合适的分片键对于分片集群的性能和扩展性至关重要。
可以是单个字段, 也可以是复合字段。
1. 范围分片
比如key的值从min~max,可以把数据进行范围分片
2. hash 分片
通过 hash(key)进行数据分段
片键值用来将集合中的文档划分为数据段,片键必须对应一个索引或索引前缀(单键、复合键),可以使用片键的值或者片键值的哈希值进行分片
4、选择片键
1. 片键值的范围更广(可以使用复合片键扩大范围)
2. 片键值的分布更平衡(可使用复合片键平衡分布)
3. 片键值不要单向增大、减小(可使用哈希片键)
5、数据段的分裂
当数据段尺寸过大,或者包含过多文档时,触发数据段分裂
只有新增、更新文档时才可能自动触发数据段分裂,数据段分裂通过更新元数据来实现
6、集群的平衡
后台运行的平衡器负责监视和调整集群的平衡,当最大和最小分片集之间的数据段数量相差过大时触发,集群中添加或移除分片时也会自动触发
7、分片集群特点
1.应用全透明
2.数据自动均衡
3.动态扩容,无需下线
8、数据回滚
由于复制延迟是不可避免的,这意味着主备节点之间的数据无法保持绝对的同步。当复制集中的主节点宕机时,备节点会重新选举成为新的主节点。那么,当旧的主节点重新加入时,必须回滚掉之前的一些“脏日志数据”,以保证数据集与新的主节点一致。主备复制集合的差距越大,发生大量数据回滚的风险就越高。
对于写入的业务数据来说,如果已经被复制到了复制集的大多数节点,则可以避免被回滚的风险。应用上可以通过设定更高的写入级别(writeConcern:majority)来保证数据的持久性。这些由旧主节点回滚的数据会被写到单独的rollback目录下,必要的情况下仍然可以恢复这些数据。
当rollback发生时,MongoDB将把rollback的数据以BSON格式存放到dbpath路径下rollback文件夹中,BSON文件的命名格式如下:...bson
mongorestore --host 192.168.192:27018 --db test --collection emp -ufox -pfox
--authenticationDatabase=admin rollback/emp_rollback.bson
9、同步源选择
MongoDB是允许通过从节点进行复制的,这会发生在以下的情况中:
效果:
所有从节点将直接与主节点同步
减少复制延迟
增加主节点负载
- 在settings.chainingAllowed开启的情况下,备节点自动选择一个最近的节点(ping命令时延最小)进行同步。settings.chainingAllowed选项默认是开启的,也就是说默认情况下从节点并不一定会选择主节点进行同步,这个副作用就是会带来延迟的增加,你可以通过下面的操作进行关闭:
//将settings.chainingAllowed设置为false,强制从节点直接从主节点同步数据,可以降低同步延迟 cfg = rs.config() cfg.settings.chainingAllowed = false rs.reconfig(cfg)
- 使用replSetSyncFrom命令临时更改当前节点的同步源,比如在初始化同步时将同步源指向从节点来降低对主节点的影响。
db.adminCommand( { replSetSyncFrom: "hostname:port" })