向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表，还遗…

  本文首先介绍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还没…

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

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

  本文介绍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…