mongodb

MongoDB removeShard的流程

向mongos发送removeShard命令 mongos向cs发送_configsvrRemoveShard命令 cs查询除了要remove的shard,是否还有别的shard在drain状态,是的话则返回失败。{"_id": {$ne: "shard1"}, "drainging": true}}} 表明同一时刻只能有一个removeShard操作。 cs查询是否要remove的shard是最后一个shard,是的话本次请求返回失败。 cs查询要remove的shard是否在drain状态,如果不是的话,则置draining状态为true,并且reload shardRegistry(缓存的shard的路由表)。日志层面记录removeShard开始 cs查询shard对应的chunk表,还遗留有多少条chunk cs查询shard对应的database表,还遗…

Read more

MongoDB中的集群选举

  本文首先介绍Raft协议的选举基本流程,然后记录mongodb主从选举的过程,主要参考Replication Internals,本文更相当于一个读书笔记性质,方便后面自己回顾。   说明:本文的step up表示节点成为primary,step down表示节点退出primary。 0. Raft协议中的选举流程   我觉得这里应该介绍一下Raft协议的基本选举内容,因为MongoDB的选举是根据Raft协议来的: 如果没有master,每个结点会主动发起选举,根据超时机制,超时时间到了才会发起。每个结点的超时时间在150ms~300ms之间随机。初始term都为0。 假设有个A结点先超时了,那么他将发起投票,将Term+1,对自己投票+1,然后发起选举给别的节点。 其他节点B, C收到消息后,发现对应的term还没…

Read more

MongoDB的主从复制之全量同步

  关于增量复制,我的上一篇博客:MongoDB主从复制之增量同步 已经大体介绍过了,本文介绍MongoDB主从复制的全量复制流程,参考官方主从复制文档和4.2的源码实现。第一部分,将会过一下大体流程;第二部分将会从代码层面大概讲一下主体流程。   说明:标题全量同步环节也叫做initial sync,但是下文提到的全量同步是全量数据的同步(data sync),其实initial sync本身除了全量数据的同步(data sync),还包括了并行的增量数据的同步(oplog sync)。这么说可能有点绕,看完这篇文章应该就懂了。 0. 前言   对于绝大多数数据库来说,数据的复制环节都是全量环节和增量环节,其中全量环节主要拷贝全量的数据,可能是打snapshot镜像复制,也可能是直接扫描表进行复制,比如mongodb里面就是挨个…

Read more

MongoDB主从复制之增量同步

  本文首先介绍3.4版本,MongoDB主从复制中增量同步的拉取和写入流程,然后介绍几个位点的区别:lastApplied,lastCommit,stableCkpt,appliedThrough。 1. 增量同步基本流程   secondary的OplogFetcher负责从源端拉取oplog,并写入到内存blocking队列OplogBuffer中;OplogBatcher负责从oplog中拉取数据,并写入到目的端(也就是当前结点)。下图是增量同步的基本流图:   同步之前,secondary会选择一个sync source作为同步的源进行全量和增量的拉取,那么同步源是如何选择的? 1.1 同步源sync source的选择   每次开启全量intial sync,创建BackgroundSync的时候,…

Read more

mongodb change stream流程

  本文介绍mongodb内部对于change stream的实现逻辑,以4.0版本为准。   change stream走的是aggregate的pipeline模式,其加了一个特殊的$changestream字段,客户端发送的change stream会被翻译成对应的$changestream stage: "pipeline" : [ { "$changeStream" : { "fullDocument" : "default", "startAtOperationTime" : Timestamp(1580867312, 3) } } ], 其本质就是一个带$match的在oplog表上的$cursor,数据拉取后经过transform转换把oplog转成change stream的event…

Read more