中国空间站图片,遵义相亲群,h5和html5的区别,深圳条幅制作开头还是介绍一下群#xff0c;如果感兴趣PolarDB ,MongoDB ,MySQL ,PostgreSQL ,Redis #xff0c;Oracle ,Oceanbase 等有问题#xff0c;有需求都可以加群群内有各大数据库行业大咖#xff0c;CTO#xff0c;可以解决你的问题。加群请加微信号 liuaustin3 #xff08;… 开头还是介绍一下群如果感兴趣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
