开头还是介绍一下群,如果感兴趣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