MongoDB原生高可用及分布式能力解析.pptxVIP

MongoDB原生高可用及分布式能力解析技术创新，变革未来

大纲MongoDB原生高可用能力：多副本（Replication）故障恢复（Failover）MongoDB原生分布式能力副本集–writeConcern/readConcern实现原理分片集群-核心架构，关键原理解析

1.MongoDB原生高可用能力

MongoDB副本集基本架构及优势副本集带来：更高的可用性更强的扩展性更好的维护性

高可用要解决的关键问题

MongoDB复制机制——oploglocal库下的一个集合：用来保存写操作所产生的增量日志（类似于MySQL中的Binlog）CappedCollection：即超出配置的最大值后，会自动删除最老的历史数据，针对Oplog的删除有特殊优化（oplogstones），以提升删除效率主节点产生新的OplogEntry，从节点通过复制Oplog并应用来保持和主节点的状态一致Oplog中包含的有：o——插入或更新的内容；op——操作类型；ns——操作执行的DB和集合；ts——操作发生的时间等

MongoDB复制机制——全量同步发生时机：新节点刚加入副本集时老的节点因为同步滞后而进入Recovering状态时全量同步包含两个阶段：数据克隆阶段：记录开始时间T1，从源端拉取所有的集合数据，不保证数据和源的一致性，记录结束时间T2增量应用阶段：应用从T1-T2期间的Oplog，达到一致性状态，全量同步结束

MongoDB复制机制——全量断点续传（4.4）4.4之前：全量同步期间，如果发生网络异常，导致同步中断，需要重头开始网络环境比较差时，大数据量很难完成全量同步；可用节点数变少，实例可用性存在隐患4.4:基于「resumetoken」机制，记录全量拉取的位点，网络异常导致同步中断后，重连时带上resumetokenreplication.initialSyncTransientErrorRetryPeriodSeconds参数决定了，同步中断后，重试的超时时间，默认24h

MongoDB复制机制——增量同步发生时机：全量同步结束后，持续同步，保持和主节点数据一致OplogFetcher线程负责拉取oplog：find命令创建tailablecursor，getMore命令批量从同步源拉取oplog，单个batch最大16MB拉取的oplogbatch放到内存中的blockingqueue中replBatcher线程负责从blockingqueue中取出batch生成新的可apply的batch，放到deque中，这里主要是因为需要控制并发，有些操作需要放到一个单独的batchoplogApplier线程负责从deque中取出batch，写oplog，然后把batch拆分，分发到多个worker线程进行并发applyfrom@张友东为了保持一致性，中间需要保存多个不同的oplog应用位点信息（appliedThrough，minValid，oplogTruncateAfterPoint），详细流程可参考：ReplicationInternals

MongoDB故障恢复——心跳机制副本集成员间两两发送「repSetHeartbeat」命令保持心跳，默认频率2s一次心跳数量=N2，N=成员数量，这个是副本集规模（上限50个成员）的主要原因心跳包包含的关键信息：副本集配置的版本和Term、发送者在副本集配置members数组中的idx和host:port、副本集名心跳回包包含的关键信息：接收者的副本集配置版本和Term、lastAppliedOpTime/lastDurableOpTime、是否是Primary等MongoDB通过心跳机制来保证：新的拓扑、成员状态和配置信息可以广播到集群中的每个节点，集群中的成员根据心跳来决定是否中止选举，发起选举，reconfig，更新成员状态心跳：副本集成员间的沟通渠道

MongoDB故障恢复——选举机制触发时机：主节点不可用新增节点（更高的Priority，prioritytakeover）主动运维，rs.stepDown()orrs.reconfig()如果超出electionTimeoutMillis（默认10秒）没有探测到主节点，Secondary节点会发起选举，发起前，检查自身条件：priority是否大于0当前状态是否够新在真正选举前，会先进行一轮空投（dry-run），避免当前