MongoDB学习专题（六）复制集和分片集群

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状态。

在文档里使用数组时，一定得注意上述问题，避免数组的更新导致同步开销被无限放大的问题。使用数组时，尽量注意：

1. 数组的元素个数不要太多，总的大小也不要太大
2. 尽量避免对数组进行更新操作
3. 如果一定要更新，尽量只在尾部插入元素，复杂的逻辑可以考虑在业务层面上来支持

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、分片集群由一下几部分组成

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" })