MongoDB 会丢数据吗？ 在次补刀MongoDB 双机热备

开头还是介绍一下群，如果感兴趣PolarDB ,MongoDB ,MySQL ,PostgreSQL ,Redis ，Oracle ,Oceanbase 等有问题，有需求都可以加群群内有各大数据库行业大咖，CTO，可以解决你的问题。加群请加微信号 liuaustin3 （共1220人左右 1 + 2 + 3 +4）新人会进入3群 

以后会争取每天一段感悟，不讨论对错，幼儿园的孩子才每件事论对错

最强大的，这个词不一定是个好词，最强大的往往是最虚弱的，那些天天和你谈格局，谈奉献，谈爱，强大的人，很可能内心和垃圾堆里面的碎玻璃一样，闪闪发光。如何和这样的人交往呢，一定要把自己碎的更厉害，发出耀眼的光，此刻他就不和你谈格局了

上期中提到了关于MongoDB 双机热备那篇文章是毒 ！本期继续补刀，不把这样害死人的思维模式捅死，我是不会罢休的。

在使用多年MongoDB 后，是否问过一个问题，MongoDB 是否会丢数据，回答是不会。为什么？

在MongoDB的使用中，除了我们熟知了 Oplogs 来进行数据的复制同步到其他的节点，同时MongoDB也提供大部分传统数据库都提供的WAL 日志，--- Journaling ,在早期的版本 4.0 前你还可以关闭Journal log 

storage.journal.enaled: false

但在4.0后的MongoDB 你不能在关闭Journal log, 这样的情况下很多人认为MongoDB 不会丢失数据，实际上不是的，这里我们全部默认MongoDB 的数据引擎为wiredTiger 并且checkpoint的工作是正常的，在这样的情况下， MongoDB 有了Journal log 有了checkpoint 的工作机制，这里看似MongoDB 应该不会丢数据，但是我们需要注意的是，看下图

在 MongoDB 中，如果是单机的模式下，从逻辑的角度来说，会丢数据按照数据库秒的默认设置，100ms 刷新Journal log ，则按照上图，会有可能最大丢失 100ms 内在MongoDB 中操作的数据。

怎么结果是丢数据，MongoDB 会丢数据，估计那些对于这个在DBEGINE 排名第四的数据库还是唯一的NOSQL数据库要各种 “踩” 了。

1  没有人告诉你MongoDB 的生产部署模式是单机， 那篇官方文档提到过，建议你部署MongoDB是单机模式。

2  有没有人告诉你，Mongodb 基本的部署模式 replica set 复制集默认的写是 w: majority 

Majority 的含义为写大多数，也就是默认复制集合的节点最少为3 ，在这样的情况下，大多数为至少每次写入数据落盘2个节点。

好，那么在这样的操作下，MongoDB 有了Journal log ， 有了Oplogs 支持下的 Replica 和 事务的大多数写作数的情况下，此时的MongoDB 的数据是安全的，在这样的情况下，我们认为操作 MongoDB 事务的情况下，数据是不会丢失的。

以下面的语句，这里插入了一条数据并且明确的标定，我们写入的情况下返回成功的前提是，节点中的大多数回馈，数据写入后，反馈事务提交成功。

db.data.insertOne(
   { name: "Simon", age : 30, level: "C" },
   { writeConcern: { w: "majority" , wtimeout: 5000 } }
)

在这样的情况下MongoDB 的数据写入是安全的，可以信赖的。

此时我们回到题目中的问题，如果你的MongoDB 是通过复制集中的协议但是你只搭建了2个节点，那么根据上述的MongoDB 数据安全和数据不丢失的理论就无从实现了，因为2个节点是不存在大多数这个概念的，在这样的情况下，我们无法从逻辑上保证数据是安全不丢失的。2节点破坏了MongoDB 的基本原理，包含Arbiter 的方式部署，这样的方式也在MongoDB 不在被推荐和建议。

所以每个数据库本身都有自己的理论和实现，并保证通过自己的理论来完成数据库不丢失数据的诺言。

所以MongoDB 双机热备就是一个伪命题，一个到处展现对于MongoDB无知的状态。

另关于MongoDB 如何清理  journal log 的问题，这里做一个回答，网络关于如果清理journal log 的部分，各种回答都有，这里注意

1  现在MongoDB 4.x 后都是WiredTiger 的数据引擎，这样的情况下不存在修改smallfile 的清理 journal log 的方案。

2  现有的Journal log 是产生100MB 大小的文件，并且在数据库做了checkpoint 的操作后，会自动删除废弃的 journal log 

3  如果需要手动删除journal log  则可以采用如下的方式进行手动删除

1 在需要删除Journal log 的MongoDB 服务器运行 

db.fsyncLock()

2  进入到Journal log 的日志目录，rm 相关文件

3  在MongoDB 中执行

db.fsyncUnlock()

以上的工作原理为，db.fsyncLock() 主要是将数据脏页全部刷新到磁盘，并停止数据的再次刷新的工作，此时就是一个人工的checkpoint点，此时可以将jounral log 进行清理。然后必须解除不能数据刷新的锁定。

最后，不懂MongoDB 基本原理，然后提出MongoDB双机热备的 T DBA 们，你们呀 ？  GET OUT