1.前言MongoDB基于wiredTiger提供的泛化SI的功能，重构了readHistory(readMajority)的能力基于wiredTiger提供的AllCommittedTimestamp API,重构了前缀一致的主从复制(Prefix-Consistent-Replication)引入混合逻辑时钟(HLC)，每个节点(Mongos/Mongod)的逻辑时钟维持在接近的值，基于此实现ChangeStream, 结合HLC与CLOCK-SI，实现分布式事务，HLC和泛化SI，CLOCK-SI两篇Paper可以作为理解MongoDB的设计的理论参考(这里并没有说MongoDB是Paper的实现)。本文尝试对Mongo的复制和分布式事务的原理进行描述，在必要的地方，对实现的正确性进行论证，希望能为MongoDB内核爱好者提供一些参考。2.MongoDB副本集事务介绍MongoDB 副本集的事务MongoDB副本集的复制是基于raft协议，相比于Paxos，raft协议实现简单，但是raft协议只支持single-master，对应的，MongoDB的副本集是主从架构，而且只有主节点支持写入操作。MongoDB副本集的事务管理，包括冲突检测，事务提交等关键操作，都只在主节点上完成。也就是说副本集的事务在事务管理方面，跟单节点逻辑基本一致。MongoDB的事务，仍然是实现了 ACID 四个特性， MongoDB使用 SI 作为事务的隔离级别。3.SI的简介SI，即SnapshotIsolation，中文称为快照隔离,是一种mvcc的实现机制，它在1995年的A Critique of ANSI SQL Isolation Levels中被正式提出。因快照时间点的选取上的不同，又分为Conventional Si 和 Generalized SI。CSI（Convensional SI）CSI 选取当前最新的系统快照作为事务的读取快照就是在事务开始的时候，获得当前db最新的snapshot，作为事务的读取的snapshot，snapshot(Ti) = start(Ti)可以减少写事务冲突发生的概率，并且提供读事务读取最新数据的能力一般我们说一个数据库支持SI隔离级别，其实默认是说支持CSI。比如RocksDB支持的SI就是CSI，WiredTiger在3.0版本之前支持的SI也是CSI。GSI（Generalized SI）GSI选择历史上的数据库快照作为事务的读取快照，因此CSI可以看作GSI的一个特例。在复制集的情况下，考虑 CSI， 对于主节点上的事务，每次事务的开始时间选取的系统 最新的 快照， 但是对于其他从节点来说, 并没有 统一的 “最新的” 快照这个概念。泛化的快照实际上是基于快照观测得到的，对于当前事务来说，我们通过选取合适的 更早时间的快照，可以让 从节点上的事务正确且无延迟的执行。举例如下:例如当前数据库的状态是， S={T1, T2, T3},  现在要开始执行T4，如果我们知道T4要修改的值，在T3上没有被修改, 那么我们在执行T4的时候， 就可以按照 T2 commit后的snashot进行读取。如何选择更早的时间点，需要满足下面的规则，符号定义Ti: 事务iXi: 被事务i修改过的X变量snapshot(Ti): 事务i的选取的快照时间start(Ti): 事务i的开始时间commit(Ti): 事务i的提交时间abort(Ti): the time when Ti is aborted.end(Ti): the time when Ti is committed or aborted.公式解释读规则G1.1, 如果变量X被本事务修改了值且读取到了新的值， 那么 读操作一定在写操作后面;G1.2, 如果事务i读取了事务j更新的变量的X， 那么一定不会有事务i更新X的操作，在事务i读取了事务j更新的变量的X这个操作前面;G1.3, 事务j的提交时间早于事务i的快照时间；G1.4, 对于任意一个会更新变量X的事务k， 那么这个事务k一定满足， 要么事务k的提交时间小于事务j， 要么这个事务k的提交时间大于事务i。写规则G2, 对于任意已经在提交历史里的两个事务，Ci, Cj, 那么一定可以保证当 事务j的commit时间戳在 事务i的观测时间段内时(snapshot(Ti), commit(Ti))， 那么他们更新的变量交集一定为空。PCSI（PREFIX-CONSISTENT SNAPSHOT ISOLATION SI）GSI 只是定义了一个范围的range，都可以作为SI使用，并没有定义具体应该选择哪个SI。PCSI 是为了复制集而设计的。对于一个事务Ti 要开S节点开始运行， 那么 S节点将必须包含这个事务所需要的所有前置事务都必须运行且提交。相比较于GSI， PCSI的读规则，额外增加了 P1.5 规则。SI的提交时间戳设置，依据 A Critique of ANSI SQL Isolation Levels 中的描述， 提交时间戳的设置应该是单调递增的。新设置的时间戳，应该大于系统中已经存在的开始时间戳和提交时间戳。SI 读取时间戳的设置，必须保证比当前系统中正在运行的事务的最小的提交时间戳还要小， 因为一旦大于当前系统中正在运行事务的最小的提交时间戳，那么这个读事务读取到的数据就是未定义的， 取决于读事务启动的时间，而不是snapshot的时间，这违背了 一致性的要求。举例如下当前已经完成的事务是T1，正在运行的事务是T2， 将要运行的读事务是T3,  如果 T3的读时间戳大于T2事务提交时间戳， 并且T2事务正在运行，等到T2事务执行完后。我们观察这个 database，就会发现 他违背了GSI，事务执行顺序如下所示是:  T1 commited and commitTs(1) -> T2 start -> T2 set commitTs(2) -> T3 start -> T3 set snapshotTs(3) -> T3 commit -> pointA -> T2 commit -> pointB那么可知， T3事务实际读取的值是 T1事务的值。但根据 pointB 点来看 GSI的读规则 1.4 的要求，会发现， 如果T3读到T1的事务的修改，那么必然要求， T3和T1之间没有空洞。但实际上 T2 是落在了 T3和T1之间的， 也就是说， 违反了 GSI 1.4的读规则。所以我们必须规定, SI 读取时间戳的设置，必须保证比当前系统中正在运行的事务的最小的提交时间戳还要小。4.MongoDB副本集时间戳应用MongoDB 4.0的复制也是利用时间戳特性解决了3.x系列MongoDB从节点复制造成从节点性能下降的关键方案。MongoDB oplog 乱序问题MongoDB主备节点的数据同步并不基于WiredTiger的wal日志来做的。相反，mongodb会将每次操作的数据变更写入到一个叫做oplog的集合里。oplog这个集合，虽然名字带有log，但实际上，它是一个MongoDB的表， 对oplog的写入，并不是 append的方式修改的， 而是呈现出一种尾部乱序的方式。对于oplog来说， oplog的读取顺序是按照TS字段来排序的， 跟上层的提交顺序无关。所以存在后开始的事务，在oplog先读取的场景。oplog 空洞因为出现了乱序，所以从节点在读取oplog的时候，就会在某些时间点出现空洞。举例如下:时间点1: oplog 顺序为: Ta -> Tb, 此时系统中还有一个事务Tc在运行时间点2: oplog 顺序为: Ta -> Tc -> Tb, 当Tc运行结束后， 因为ts的顺序， 看起来是将Tc插入到了Ta和Tb之间。那么当 从节点 在时间点1 reply 到 Tb的时候， 实际上是漏了 Tc的，这个就是oplog的空洞， 他产生的原因是因为，从节点如果每次读取oplog最新的数据，就有可能会得到一个不连续的数据, 例如 时间点1上 Ta-> Tb. 这就是oplog空洞。在具体复制逻辑中，我们必须想办法来从节点读取到含有空洞的oplog数据。这也是GSI的要求， snapshot的选取不能含有空洞。因为 oplog的Ts是mongo上层给的，我们很容易知道哪些事务有哪些ts， 我们再将这个ts 作为事务的commitTs 放到 oplog存储的事务里， 这样我们读取 oplog的顺序事务的可见性顺序相一致了，在这种情况下，我们就可以 根据 活跃事务列表， 就可以将oplog 分为两个部分，假设活跃commitTs列表的事务是 {T10, T11, T12}, 活跃事务列表是 {T10, T11, T12, T13, T14}, 那么意味着， 目前有 T10, T11, T12, T13, T14 再运行，并且 T10, T11, T12 已经设置了 commitTs， 又因为 上面讨论的 commitTs 是单调递增的， 那么我们可知, T13, T14 的commitTs 一定大于 maxCommitTs(T10, T11, T12), 而且我们还可知， minCommitTs(T10,T11,T12) 就是全局最小的 commitTs， 而小于这些的 commitTs的事务，因为不在 活跃事务列表里了， 表示已经提交了， 那么我们可以知道， oplog ts 在 全局最小的 commitTs 之前的， 就是都提交了的， oplog 按照 commitTs 排序后，如下所示… Tx | minCommitTs(T10,T11,T12) | …我们可以知道 T9， 或者说小于 minCommitTs(T10,T11,T12) 都是无空洞，因为系统不会再提交小于 minCommitTs(T10,T11,T12) 的事务到oplog里了， 所以从节点可以直接恢复这里的数据。上面说的oplog minCommitTs(T10,T11,T12) 在 mongodb里，就是特殊的timestamp， 这个后文会讲。通过上面的方案，我们可以解决空洞的问题。这个时候，从节点每次恢复数据的时候，将读取的snapshot，设置为上一次恢复的Ts(同样也是无空洞的Ts)， 这样的话， 从节点的恢复数据和读取数据也就做到了互不冲突。从而解决了 3.x系列的 从节点同步数据造成节点性能下降的问题。

MongoDB经典故障系列一：数据库频繁启动失败怎么办？MongoDB经典故障系列二：如何限制最大连接数？     MongoDB经典故障系列三：副本集延迟太高怎么办？MongoDB经典故障系列四：调整oplog大小，引起从库宕机怎么办？MongoDB经典故障系列五：sharding集群执行sh.stopBalancer()命令被卡住怎么办？MongoDB经典故障系列六：CPU利⽤率太⾼怎么办？

华为云数据库精选特惠活动火热进行中，爆款产品低至4.5折，新人享3.9折迁移价，机“惠”难得，购买请戳下图。

MongoDB副本集延迟太高，数据读取时间过长怎么办？不要慌，菊长教您一个小妙招：在集合创建的时候，就建立好索引，然后按照索引去寻找您所需要的数据。如果觉得比较麻烦，华为云文档数据库服务DDS了解一下。DDS服务100%兼容MongoDB，云上托管实例，无需客户操心。云数据库特惠专场来袭，10元尝鲜高性能云数据库1个月，单品包年3折起，迁移用户额外赠送6个月使用时长；还有云服务器、存储、域名等爆款组合包年低至34折，速来抢购！点击抢购

1.    特性概述 对于mongodb分片集群来说，在默认情况下一个集合的数据都是存储在一个shard上。如果一个集合的数据量非常大，就会导致不同shard之间的业务负载有很大差异，这种情况显然是不合理的。所以大多数情况下都应该对集合开启分片，也就是执行shardCollection，这个命令的作用就是开启集合在不同shard之间的自动均衡。2.    命令原理 shardCollection命令的基本要素是指定集合（namespace）和片键（key）；片键是集合文档中的一个字段，片键字段所对应的值就是collection切分为不同chunk的依据。shard概念及片键选择建议请参考https://docs.mongodb.com/manual/sharding/3.    约束l  如果是新集合，选择片键后，mongo会在片键上创建索引。l  一个集合不能同时选择多个片键。l  不能update片键对应字段。l  如果集合不为空，则在shardCollection之前需要在对应片键上提前创好索引。l  分片集合不能在片键以外的字段创建唯一索引。l  选择片键时不能有片键以外的字段存在唯一索引。4.    处理逻辑shardCollection命令在mongos上执行，命令入口cluster_shard_collection_cmd.cpp:1)        cluster_shard_collection_cmd.cpp的run方法：可以看到命令内部有一个是否retry的判断，后面部分判断和rollback的逻辑都是为了命令重试的场景因为创建片键的限制比较多，所以校验逻辑也会比较长。除了命令入参的合法性校验以外的核心就是usefulIndex校验。因为对于有数据的集合，在片键上有合法索引才能shardCollection。上面是入参校验。涉及到的两个知识点：collation参考 http://www.mongoing.com/archives/3912， view参考 http://www.mongoing.com/archives/3502。合法索引校验。校验完成后会调用harding_catalog_client_impl.cpp的shardCollection方法。2)        sharding_catalog_client_impl.cpp的shardCollection方法：该方法主要用来：l  获取集合的分布式锁，防止shardCollection过程中集合被删除或重复调用shardCollection。l  在config.changelog中写入记录shardCollection.start。l  调用config的shard_collection.cpp的run方法。3)        shard_collection.cpp的run方法： 该方法有两个主要分支，如果是新集合直接走run_normal方法，如果不是新集合走shardCollectionExist2方法。l  先看run_normal方法的实现： 主要工作是创建集合和索引的元数据对于hash分片的新集合有一个特殊处理，这种场景会先算出一批拆分点，并同时创出一批chunk（numShards-1）。拆分原理是把hash值的范围进行均分（-MIN long, +MAX long），long类型是64位，所以hash的最大值是2^64，这样做的好处是可以一开始就保证数据的均匀分布，减少迁移。如果不符合该条件则调用_create_one_chunk方法创建一个chunk。l  接着看shardCollectionExist2方法的实现：可以发现对有数据集合执行shardCollection的逻辑要复杂一些 一开始也是执行run_normal方法，但这种场景下入参newCmdObj是不同的。在创建集合元数据时会先创建一个临时的集合。等临时集合创建好后，会把旧集合的数据和索引拷贝过来，然后重命名这个临时集合。至此shardCollection的主要流程解释完成。

华为开发者大会2020（Cloud）是华为面向ICT（信息与通信）领域全球开发者的年度顶级旗舰活动。大会旨在搭建一个全球性的交流和实践平台，开放华为30年积累的ICT技术和能力，以“鲲鹏+昇腾”硬核双引擎，为开发者提供澎湃动力，改变世界，变不可能为可能。我们期待与你共创计算新时代在一起，梦飞扬！

华为开发者大会2020（Cloud）是华为面向ICT（信息与通信）领域全球开发者的年度顶级旗舰活动。大会旨在搭建一个全球性的交流和实践平台，开放华为30年积累的ICT技术和能力，以“鲲鹏+昇腾”硬核双引擎，为开发者提供澎湃动力，改变世界，变不可能为可能。我们期待与你共创计算新时代在一起，梦飞扬！

1月4日，2019年MongoDB中文社区年终盛会在深圳时代大厦举行，大会邀请了众多知名云服务商和业内技术大咖，共同畅谈云时代下MongoDB如何寻求突破，如何给企业带来巨大红利。华为云NoSQL数据库负责人胡达与会并发表了《云原生时代的MongoDB》的主题演讲，表示云原生数据库在性价比、数据可靠性、弹性伸缩等方面十分具有优势，对企业发展具有重大意义。华为云NoSQL数据库负责人胡达现场分享云原生时代下的MongoDB随着数字化和智能化进程的加快，数据上云成为了各大企业的首选，而MongoDB也在数字化进程中不断加速云化过程，云服务也愈来愈多样，胡达对目前云上MongoDB的典型部署架构作了简要分析。目前国内云厂商的MongoDB兼容云服务基本是以社区开源版本的托管为主，通过用云硬盘替代本地硬盘，发挥了一部分云计算优势，实现存储容量快速扩展；提供一站式的部署、管理、运维能力，在数据可靠性、安全性、备份恢复等方面有一定的易用性改进，减轻了DBA的工作负担。但是，相比国外友商的基于云原生架构同类云服务产品，在弹性、高可用、可靠性、性能稳定等方面仍存在差距。会上胡达分享了云原生时代的MongoDB，认为未来的方向是计算存储分离架构下的Serverless模式，给用户提供更简单易用的使用体验。华为云GeminiDB的更多可能性基于云时代下客户数据上云，企业的数字化转型，客户对MongoDB的使用，大数据量的压力这些痛点，胡达在会上重点介绍了华为云数据库GeminiDB，这是一款基于华为自主研发的计算存储分离架构的分布式多模NoSQL数据库服务，100%兼容MongoDB接口，并提供高性能、高可靠的优势。与市面上各类MongoDB云服务相比，GeminiDB for MongoDB API构筑了以下优势：一是分钟级计算节点扩容和秒级存储扩容，扩容性能提升百倍，满足敏捷业务弹性需要。二是高性价比，同等成本下提升了3倍写性能。三是数据高可靠，基于分布式存储的数据副本故障快速恢复能力，副本重建时长缩短10倍+。此外，GeminiDB for MongoDB API支持单套实例最大100TB数据，N-1个节点故障容忍，具备一键部署、监控报警等服务能力。胡达表示，华为云数据库会充分利用华为软硬件优势持续构建业内领先的技术和服务，打造真正的云原生MongoDB API兼容的云服务。未来，云原生数据库，我们可以做得更好。欲了解更多云数据库详情，请前往华为云官网：https://www.huaweicloud.com/product/geminidb.html

1 MongoDB简介MongoDB是一个基于分布式文件存储的数据库。由C++语言编写。旨在为WEB应用提供可扩展的高性能数据存储解决方案。MongoDB是一个介于关系数据库和非关系数据库之间的产品，是非关系数据库当中功能最丰富，最像关系数据库的。它支持的数据结构非常松散，是类似json的bson格式，因此可以存储比较复杂的数据类型。Mongo最大的特点是它支持的查询语言非常强大，其语法有点类似于面向对象的查询语言，几乎可以实现类似关系数据库单表查询的绝大部分功能，而且还支持对数据建立索引。2 环境信息2.1 环境信息类别子项版本获取地址OSCentOS7.5 Aarch64href="https://www.centos.org/download/" https://www.centos.org/download/服务器配置16U16GB50GB软件MongoDB3.6.13https://github.com/mongodb/mongo/archive/r3.6.13.tar.gz3 软件移植3.1 环境准备：OS安装类型：CentOS-7.5-aarch64-1804。 注：操作系统安装使用最小简化版安装(如上图)，其余步骤安装一般安装操作系统步骤即可。网络安装arm版MongoDB的所在服务器上必须联网，能够使用网络yum源，否则执行脚本会失败。 3.1.1 相关软件下载上传：无  3.2 安装MongoDB 1、 上传以下脚本至要安装MongoDB的服务器上的任意目录，如/opt。（mongodb_install.sh）2、 执行如下命令添加执行权限：    chmod +x /opt/mongodb_install.sh3、 执行脚本，提示mongodb install success表示安装成功    sh /opt/mongodb_install.sh 3.3 验证执行1.进入mongodb安装目录/bin，执行./mongod开启服务 2．执行./mongo，使用客户端连接，简单执行增加和查询  

华为云文档数据库DDS是一款兼容MongoDB协议，在华为云高性能、高可用、高安全、可弹性伸缩的基础上，提供了一键部署、弹性扩容、容灾、备份、恢复、监控等服务能力的产品。目前，DDS社区版新增了审计日志、库表级时间点恢复、兼容MongoDB4.0版本三大价值特性，功能更完善，性能进一步提升。 一、审计策略灵活设置，保留时间长达2年华为云DDS服务社区版集群、副本集和单节点支持审计日志，保留天数长达732天，且价格亲民。（1）华为云审计日志除了能对整个实例审计之外，还支持只设置部分表，比如有些日志表不需要审计的，则可以不进行审计，也可以根据语句类型来审计。目前各大云服务的审计日志大多只能做到实例级，也就是所有表都审计，没有那么灵活。华为云DDS既考虑了客户的审计使用，又能让客户灵活设置敏感表的审计，节省了审计成本。（2）审计日志保留时间长达2年。二、库表级时间点恢复灵活迅速华为云DDS采取了灵活性和恢复效率合一的方式，单次恢复可以支持每个库表恢复到不同时间点，比如游戏场景，可能每个局服开局时间不一致，华为云DDS可支持单次多时间点回档。首先选择基准时间点，我们通过这个基准时间点来选择基准全备，然后展示基准可恢复时间区间，单次恢复每个库表可以在这个时间区间里面选择任意不同的时间点。三、全面兼容MongoDB社区4.0版本华为云DDS目前支持分片集群（Sharding）、副本集（ReplicaSet）和单节点（Single）三种部署架构，三大架构全面兼容MongoDB社区4.0版。华为云DDS服务三大价值特性的加持使其领先行业，在市面上具有极大优势，社区版现已发布，如想体验领先的服务，想企业更好更快地上云，敬请前往华为云官网：https://www.huaweicloud.com/product/dds.html?utm_source=wechat&utm_medium=officialaccount&utm_campaign=dds_1011&utm_content=sjk_dds

#化鲲为鹏，我有话说#此前我在发表（shui）帖子(tie)的时候，有一篇帖子讲到了关于MongoDB的安装以及对其安全账户的一些配置问题，紧接着过了两天在网上冲浪的时候看到了一篇关于MongoDB未授权访问的漏洞，吓得赶紧排查核实了一下。爱发帖（shui）子（tie）的我赶紧给大家分享一哈～哈哈哈环境：华为云鲲鹏服务器    镜像：Ubuntu 18.04 64bit ARM架构（Debian系）主角MongoDB安装历程，传送门：https://bbs.huaweicloud.com/forum/thread-24370-1-1.html此处的版本为3.6MongoDB shell version v3.6.3connecting to: mongodb://127.0.0.1:27017MongoDB server version: 3.6.3一、漏洞危害对外开放的MongoDB服务（公网开放），存在未配置访问认证授权漏洞，无需认证连接数据库后对数据库进行任意操作（常见的增、删、改、查操作），存在严重的数据泄露风险。二、漏洞成因MongoDB服务安装后，默认未开启权限验证。如果服务监听在0.0.0.0，则可远程无需授权访问数据库。3.0之前版本的MongoDB,默认监听在0.0.0.0，3.0及之后版本默认监听在127.0.0.1。3.0之前版本，如未添加用户管理员账号及数据库账号，使用--auth参数启动时，在本地通过127.0.0.1仍可无需账号密码登陆访问数据库，远程访问则提示需认证；3.0及之后版本，使用--auth参数启动后，无账号则本地和远程均无任何数据库访问权限。三、漏洞验证MongoDB存在未授权访问漏洞时，执行show dbs命令，无报错信息，列表存在默认库local库，则判断存在未授权访问（local库即便删除，重启MongoDB后仍会生成）。赶紧检查一波服务器，不过咱们这版本这么高，应该不可能存在漏洞吧～、mongo --authenticationMechanism argMongoDB shell version v3.6.3connecting to: mongodb://127.0.0.1:27017MongoDB server version: 3.6.3> show dbs数据库回显error，msg称未验证的admin用户来执行命令。四、整改建议    方案1：本地监听如MongoDB只需在本地使用，建议只在本地开启监听服务，使用--bind_ip 127.0.0.1绑定监听地址。$ mongod --bind_ip 127.0.0.1 --dbpath /tmp/test###本地监听端口即可或：在配置文件中指定监听IP，Linux下默认配置文件为/etc/mongod.conf。# network interfacesnet:  port: 27017  bindIp: 127.0.0.1指定配置文件启动mongod --config /etc/mongod.conf方案2：启动基于角色的登录认证功能上面的传送门里有启用登录认证的教程～溜了溜了～水完贴就溜了