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

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

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

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

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

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

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

go 复制代码
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 事务的情况下,数据是不会丢失的。

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

go 复制代码
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 服务器运行

go 复制代码
db.fsyncLock()

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

3 在MongoDB 中执行

go 复制代码
db.fsyncUnlock()

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

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

相关推荐
RestCloud5 小时前
SQL Server到Hive:批处理ETL性能提升30%的实战经验
数据库·api
RestCloud5 小时前
为什么说零代码 ETL 是未来趋势?
数据库·api
ClouGence7 小时前
CloudCanal + Paimon + SelectDB 从 0 到 1 构建实时湖仓
数据库
DemonAvenger14 小时前
NoSQL与MySQL混合架构设计:从入门到实战的最佳实践
数据库·mysql·性能优化
AAA修煤气灶刘哥1 天前
后端人速藏!数据库PD建模避坑指南
数据库·后端·mysql
RestCloud1 天前
揭秘 CDC 技术:让数据库同步快人一步
数据库·api
得物技术1 天前
MySQL单表为何别超2000万行?揭秘B+树与16KB页的生死博弈|得物技术
数据库·后端·mysql
可涵不会debug2 天前
【IoTDB】时序数据库选型指南:工业大数据场景下的技术突围
数据库·时序数据库
ByteBlossom2 天前
MySQL 面试场景题之如何处理 BLOB 和CLOB 数据类型?
数据库·mysql·面试
麦兜*2 天前
MongoDB Atlas 云数据库实战:从零搭建全球多节点集群
java·数据库·spring boot·mongodb·spring·spring cloud