前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >MongoDB 会丢数据吗? 在次补刀MongoDB 双机热备

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

作者头像
AustinDatabases
发布2023-09-06 10:53:47
8341
发布2023-09-06 10:53:47
举报
文章被收录于专栏:AustinDatabases

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

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

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

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

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

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

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

代码语言:javascript
复制
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 服务器运行

代码语言:javascript
复制
db.fsyncLock()

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

3 在MongoDB 中执行

代码语言:javascript
复制
db.fsyncUnlock()

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

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

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2023-08-29,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 AustinDatabases 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
相关产品与服务
数据库
云数据库为企业提供了完善的关系型数据库、非关系型数据库、分析型数据库和数据库生态工具。您可以通过产品选择和组合搭建,轻松实现高可靠、高可用性、高性能等数据库需求。云数据库服务也可大幅减少您的运维工作量,更专注于业务发展,让企业一站式享受数据上云及分布式架构的技术红利!
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档