复盘：记录一次 mongo 集群“数据丢失”

已于 2023-04-09 14:41:51 修改
阅读量1k 收藏
点赞数
文章标签： mongodb 数据库
于 2023-04-09 14:37:58 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/u013570834/article/details/130041991
版权
文章描述了一次在MongoDB一主一从一仲裁集群中数据丢失的测试情况，详细解释了数据丢失的原因是由于仲裁节点不会提升为主，导致从节点先启动时成为新主，从而丢失未同步的数据。通过示例展示了如何复现这一问题，并讨论了MongoDB的WiredTiger日志系统在防止数据丢失方面的机制。
摘要由CSDN通过智能技术生成

前言

背景故事

记一次 mongo 集群数据丢失。搭建了一套一主一从一仲裁的 mongo 集群，随后测试在测高可用时，告知数据丢失

据测试原话，杀从 -> 新增数据 -> 杀主 -> 启动原主 -> 启动原从 -> 数据丢失，关键在于她能百分百复现，而我却不能，而且还是很轻易的复现

直接抛答案，测试给我演示的是，杀从 -> 新增数据 -> 杀主 -> 启动原从 -> 启动原主 -> 数据丢失

原因也很简单，仲裁节点永远不会提升为主，当主从都挂了后，先启动的原从就会提升为主，后启动的原主就会降为从。主从同步只会从同步主，此时数据丢失

环境介绍

本机模拟一主一从一仲裁的 mongo 集群

MongoDB 版本：mongodb-community 6.0.4

主从仲裁
localhost:27017localhost:37017localhost:47017

集群搭建

37017.conf、47017.cof 同 27017.conf，只需将 27017 换成 37017、47017

systemLog:
  destination: file
  path: /tmp/log/mongodb/27017.log
  logAppend: true
storage:
  dbPath: /tmp/27017
net:
  port: 27017
  bindIp: 127.0.0.1, ::1 
  ipv6: true
replication:
  replSetName: rs0

# 创建存储目录
mkdir /tmp/27017
mkdir /tmp/27017
# 分别启动三台实例
mongod -f 27017.conf
mongod -f 37017.conf
mongod -f 47017.conf

先连上 27017， mongosh --port 27017

rs.initiate({_id: "rs0", members: [{ _id: 0 , host: "localhost:27017" }]}) // 初始化后该实例就是 master
rs.add("localhost:37017") // 增加从节点

db.adminCommand({ // 设置默认读写关注
  "setDefaultRWConcern" : 1,
  "defaultWriteConcern" : {
    "w" : 1
  },
  "defaultReadConcern" : { "level" : "local" }
})

rs.addArb("localhost:47017") // 增加仲裁节点

问题复现

演示一

杀从 -> 新增数据 -> 杀主 -> 启动原主 -> 启动原从 -> 数据丢失（没复现）

  1. 直接 kill 掉从，连上集群 mongosh mongodb://localhost:27017,localhost:37017,localhost:47017，查看当前集群状态

    rs.status().members;
[
  {
    _id: 0,
    name: 'localhost:27017',
    health: 1,
    state: 1,
    stateStr: 'PRIMARY',
    uptime: 2176,
    optime: { ts: Timestamp({ t: 1681018937, i: 1 }), t: Long("1") },
    optimeDate: ISODate("2023-04-09T05:42:17.000Z"),
    lastAppliedWallTime: ISODate("2023-04-09T05:42:17.943Z"),
    lastDurableWallTime: ISODate("2023-04-09T05:42:17.943Z"),
    syncSourceHost: '',
    syncSourceId: -1,
    infoMessage: '',
    electionTime: Timestamp({ t: 1681016897, i: 1 }),
    electionDate: ISODate("2023-04-09T05:08:17.000Z"),
    configVersion: 4,
    configTerm: 1,
    self: true,
    lastHeartbeatMessage: ''
  },
  {
    _id: 1,
    name: 'localhost:37017',
    health: 0,
    state: 8,
    stateStr: '(not reachable/healthy)',
    uptime: 0,
    optime: { ts: Timestamp({ t: 0, i: 0 }), t: Long("-1") },
    optimeDurable: { ts: Timestamp({ t: 0, i: 0 }), t: Long("-1") },
    optimeDate: ISODate("1970-01-01T00:00:00.000Z"),
    optimeDurableDate: ISODate("1970-01-01T00:00:00.000Z"),
    lastAppliedWallTime: ISODate("2023-04-09T05:37:17.829Z"),
    lastDurableWallTime: ISODate("2023-04-09T05:37:17.829Z"),
    lastHeartbeat: ISODate("2023-04-09T05:42:18.141Z"),
    lastHeartbeatRecv: ISODate("2023-04-09T05:37:23.310Z"),
    pingMs: Long("0"),
    lastHeartbeatMessage: 'Error connecting to localhost:37017 (::1:37017) :: caused by :: Connection refused',
    syncSourceHost: '',
    syncSourceId: -1,
    infoMessage: '',
    configVersion: 4,
    configTerm: 1
  },
  {
    _id: 2,
    name: 'localhost:47017',
    health: 1,
    state: 7,
    stateStr: 'ARBITER',
    uptime: 781,
    lastHeartbeat: ISODate("2023-04-09T05:42:17.620Z"),
    lastHeartbeatRecv: ISODate("2023-04-09T05:42:17.619Z"),
    pingMs: Long("0"),
    lastHeartbeatMessage: '',
    syncSourceHost: '',
    syncSourceId: -1,
    infoMessage: '',
    configVersion: 4,
    configTerm: 1
  }
]

  2. 插入数据

    db.col.insert({"name": "张三"})
{
  acknowledged: true,
  insertedIds: { '0': ObjectId("643252839561b614ad68d8b9") }
}

  3. 直接 kill 掉主，确认当前只有仲裁节点 ps -ef | grep mongod

      501 22005 57723   0  1:38下午 ttys001    0:03.94 mongosh mongodb://localhost:27017,localhost:37017,localhost:47017/?serverSelectionTimeou TERM_PROGRAM=Apple_Terminal SHELL=/bin/zsh
    0 30435 99065   0  1:53下午 ttys007    0:00.01 grep mongod
    0 11804  9349   0  1:21下午 ttys008    0:18.77 bin/mongod -f conf/47017.conf

  4. 先后启动主从，并确认当前集群状态

    rs.status().members;
[
  {
    _id: 0,
    name: 'localhost:27017',
    health: 1,
    state: 1,
    stateStr: 'PRIMARY',
    uptime: 40,
    optime: { ts: Timestamp({ t: 1681019814, i: 1 }), t: Long("3") },
    optimeDate: ISODate("2023-04-09T05:56:54.000Z"),
    lastAppliedWallTime: ISODate("2023-04-09T05:56:54.970Z"),
    lastDurableWallTime: ISODate("2023-04-09T05:56:54.970Z"),
    syncSourceHost: '',
    syncSourceId: -1,
    infoMessage: '',
    electionTime: Timestamp({ t: 1681019794, i: 1 }),
    electionDate: ISODate("2023-04-09T05:56:34.000Z"),
    configVersion: 4,
    configTerm: 3,
    self: true,
    lastHeartbeatMessage: ''
  },
  {
    _id: 1,
    name: 'localhost:37017',
    health: 1,
    state: 2,
    stateStr: 'SECONDARY',
    uptime: 17,
    optime: { ts: Timestamp({ t: 1681019814, i: 1 }), t: Long("3") },
    optimeDurable: { ts: Timestamp({ t: 1681019814, i: 1 }), t: Long("3") },
    optimeDate: ISODate("2023-04-09T05:56:54.000Z"),
    optimeDurableDate: ISODate("2023-04-09T05:56:54.000Z"),
    lastAppliedWallTime: ISODate("2023-04-09T05:56:54.970Z"),
    lastDurableWallTime: ISODate("2023-04-09T05:56:54.970Z"),
    lastHeartbeat: ISODate("2023-04-09T05:57:01.702Z"),
    lastHeartbeatRecv: ISODate("2023-04-09T05:57:02.630Z"),
    pingMs: Long("0"),
    lastHeartbeatMessage: '',
    syncSourceHost: 'localhost:27017',
    syncSourceId: 0,
    infoMessage: '',
    configVersion: 4,
    configTerm: 3
  },
  {
    _id: 2,
    name: 'localhost:47017',
    health: 1,
    state: 7,
    stateStr: 'ARBITER',
    uptime: 38,
    lastHeartbeat: ISODate("2023-04-09T05:57:02.981Z"),
    lastHeartbeatRecv: ISODate("2023-04-09T05:57:02.986Z"),
    pingMs: Long("0"),
    lastHeartbeatMessage: '',
    syncSourceHost: '',
    syncSourceId: -1,
    infoMessage: '',
    configVersion: 4,
    configTerm: 3
  }
]

  5. 查询数据

    db.col.findOne();
{ _id: ObjectId("643252839561b614ad68d8b9"), name: '张三' }

演示二

杀从 -> 新增数据 -> 杀主 -> 启动原主 -> 启动原从 -> 数据丢失（复现）

  1. 直接 kill 掉从，连上集群 mongosh mongodb://localhost:27017,localhost:37017,localhost:47017，查看当前集群状态

    rs.status().members;
[
  {
    _id: 0,
    name: 'localhost:27017',
    health: 1,
    state: 1,
    stateStr: 'PRIMARY',
    uptime: 192,
    optime: { ts: Timestamp({ t: 1681019975, i: 1 }), t: Long("3") },
    optimeDate: ISODate("2023-04-09T05:59:35.000Z"),
    lastAppliedWallTime: ISODate("2023-04-09T05:59:35.034Z"),
    lastDurableWallTime: ISODate("2023-04-09T05:59:35.034Z"),
    syncSourceHost: '',
    syncSourceId: -1,
    infoMessage: '',
    electionTime: Timestamp({ t: 1681019794, i: 1 }),
    electionDate: ISODate("2023-04-09T05:56:34.000Z"),
    configVersion: 4,
    configTerm: 3,
    self: true,
    lastHeartbeatMessage: ''
  },
  {
    _id: 1,
    name: 'localhost:37017',
    health: 0,
    state: 8,
    stateStr: '(not reachable/healthy)',
    uptime: 0,
    optime: { ts: Timestamp({ t: 0, i: 0 }), t: Long("-1") },
    optimeDurable: { ts: Timestamp({ t: 0, i: 0 }), t: Long("-1") },
    optimeDate: ISODate("1970-01-01T00:00:00.000Z"),
    optimeDurableDate: ISODate("1970-01-01T00:00:00.000Z"),
    lastAppliedWallTime: ISODate("2023-04-09T05:59:25.029Z"),
    lastDurableWallTime: ISODate("2023-04-09T05:59:25.029Z"),
    lastHeartbeat: ISODate("2023-04-09T05:59:33.869Z"),
    lastHeartbeatRecv: ISODate("2023-04-09T05:59:32.804Z"),
    pingMs: Long("0"),
    lastHeartbeatMessage: 'Error connecting to localhost:37017 (::1:37017) :: caused by :: Connection refused',
    syncSourceHost: '',
    syncSourceId: -1,
    infoMessage: '',
    configVersion: 4,
    configTerm: 3
  },
  {
    _id: 2,
    name: 'localhost:47017',
    health: 1,
    state: 7,
    stateStr: 'ARBITER',
    uptime: 190,
    lastHeartbeat: ISODate("2023-04-09T05:59:35.145Z"),
    lastHeartbeatRecv: ISODate("2023-04-09T05:59:35.145Z"),
    pingMs: Long("0"),
    lastHeartbeatMessage: '',
    syncSourceHost: '',
    syncSourceId: -1,
    infoMessage: '',
    configVersion: 4,
    configTerm: 3
  }
]

  2. 插入数据

    db.col.insert({"name": "李四"})
{
  acknowledged: true,
  insertedIds: { '0': ObjectId("643254789561b614ad68d8ba") }
}

  3. 直接 kill 掉主，确认当前只有仲裁节点 ps -ef | grep mongod

      501 22005 57723   0  1:38下午 ttys001    0:04.96 mongosh mongodb://localhost:27017,localhost:37017,localhost:47017/?serverSelectionTimeou TERM_PROGRAM=Apple_Terminal SHELL=/bin/zsh
    0 35004 94552   0  2:01下午 ttys002    0:00.00 grep mongod
    0 11804  9349   0  1:21下午 ttys008    0:23.09 bin/mongod -f conf/47017.conf

  4. 先启动原从，确认当前集群状态，可见原从晋级为主节点

    rs.status().members;
[
  {
    _id: 0,
    name: 'localhost:27017',
    health: 0,
    state: 8,
    stateStr: '(not reachable/healthy)',
    uptime: 0,
    optime: { ts: Timestamp({ t: 0, i: 0 }), t: Long("-1") },
    optimeDurable: { ts: Timestamp({ t: 0, i: 0 }), t: Long("-1") },
    optimeDate: ISODate("1970-01-01T00:00:00.000Z"),
    optimeDurableDate: ISODate("1970-01-01T00:00:00.000Z"),
    lastAppliedWallTime: ISODate("1970-01-01T00:00:00.000Z"),
    lastDurableWallTime: ISODate("1970-01-01T00:00:00.000Z"),
    lastHeartbeat: ISODate("2023-04-09T06:03:41.628Z"),
    lastHeartbeatRecv: ISODate("1970-01-01T00:00:00.000Z"),
    pingMs: Long("0"),
    lastHeartbeatMessage: 'Error connecting to localhost:27017 (::1:27017) :: caused by :: Connection refused',
    syncSourceHost: '',
    syncSourceId: -1,
    infoMessage: '',
    configVersion: -1,
    configTerm: -1
  },
  {
    _id: 1,
    name: 'localhost:37017',
    health: 1,
    state: 1,
    stateStr: 'PRIMARY',
    uptime: 32,
    optime: { ts: Timestamp({ t: 1681020221, i: 1 }), t: Long("4") },
    optimeDate: ISODate("2023-04-09T06:03:41.000Z"),
    lastAppliedWallTime: ISODate("2023-04-09T06:03:41.569Z"),
    lastDurableWallTime: ISODate("2023-04-09T06:03:41.569Z"),
    syncSourceHost: '',
    syncSourceId: -1,
    infoMessage: '',
    electionTime: Timestamp({ t: 1681020201, i: 1 }),
    electionDate: ISODate("2023-04-09T06:03:21.000Z"),
    configVersion: 4,
    configTerm: 4,
    self: true,
    lastHeartbeatMessage: ''
  },
  {
    _id: 2,
    name: 'localhost:47017',
    health: 1,
    state: 7,
    stateStr: 'ARBITER',
    uptime: 31,
    lastHeartbeat: ISODate("2023-04-09T06:03:41.581Z"),
    lastHeartbeatRecv: ISODate("2023-04-09T06:03:41.594Z"),
    pingMs: Long("0"),
    lastHeartbeatMessage: '',
    syncSourceHost: '',
    syncSourceId: -1,
    infoMessage: '',
    configVersion: 4,
    configTerm: 4
  }
]

  5. 查询数据，因为从再插入数据之前就挂了，所以从根本没有拉取到插入的数据，所以现在数据是没有的

    db.col.findOne({"name": "李四"})
null

  6. 再启动原主，确认当前集群状态，可见原主降级为了从节点

    [
  {
    _id: 0,
    name: 'localhost:27017',
    health: 1,
    state: 2,
    stateStr: 'SECONDARY',
    uptime: 5,
    optime: { ts: Timestamp({ t: 1681020431, i: 1 }), t: Long("4") },
    optimeDurable: { ts: Timestamp({ t: 1681020431, i: 1 }), t: Long("4") },
    optimeDate: ISODate("2023-04-09T06:07:11.000Z"),
    optimeDurableDate: ISODate("2023-04-09T06:07:11.000Z"),
    lastAppliedWallTime: ISODate("2023-04-09T06:07:11.642Z"),
    lastDurableWallTime: ISODate("2023-04-09T06:07:11.642Z"),
    lastHeartbeat: ISODate("2023-04-09T06:07:18.324Z"),
    lastHeartbeatRecv: ISODate("2023-04-09T06:07:18.583Z"),
    pingMs: Long("0"),
    lastHeartbeatMessage: '',
    syncSourceHost: 'localhost:37017',
    syncSourceId: 1,
    infoMessage: '',
    configVersion: 4,
    configTerm: 4
  },
  {
    _id: 1,
    name: 'localhost:37017',
    health: 1,
    state: 1,
    stateStr: 'PRIMARY',
    uptime: 251,
    optime: { ts: Timestamp({ t: 1681020431, i: 1 }), t: Long("4") },
    optimeDate: ISODate("2023-04-09T06:07:11.000Z"),
    lastAppliedWallTime: ISODate("2023-04-09T06:07:11.642Z"),
    lastDurableWallTime: ISODate("2023-04-09T06:07:11.642Z"),
    syncSourceHost: '',
    syncSourceId: -1,
    infoMessage: '',
    electionTime: Timestamp({ t: 1681020201, i: 1 }),
    electionDate: ISODate("2023-04-09T06:03:21.000Z"),
    configVersion: 4,
    configTerm: 4,
    self: true,
    lastHeartbeatMessage: ''
  },
  {
    _id: 2,
    name: 'localhost:47017',
    health: 1,
    state: 7,
    stateStr: 'ARBITER',
    uptime: 250,
    lastHeartbeat: ISODate("2023-04-09T06:07:19.821Z"),
    lastHeartbeatRecv: ISODate("2023-04-09T06:07:19.821Z"),
    pingMs: Long("0"),
    lastHeartbeatMessage: '',
    syncSourceHost: '',
    syncSourceId: -1,
    infoMessage: '',
    configVersion: 4,
    configTerm: 4
  }
]

  7. 连接到原主 mongosh mongodb://localhost:27017，并查询数据，原来写入主的数据也丢失了

    rs.secondaryOk() // 允许读取从节点
db.col.findOne({"name": "李四"})
null

心路历程

当听到 mongo 集群丢数据时，我就觉得有点不可思议，一般向这种非内存数据库都会有 WAL 保证

去官网查查阅 FAQ:MongoDB Storage

Starting in version 3.6, MongoDB configures WiredTiger to create checkpoints (i.e. write the snapshot data to disk) at intervals of 60 seconds

The WiredTiger journal persists all data modifications between checkpoints. If MongoDB exits between checkpoints, it uses the journal to replay all data modified since the last checkpoint

At every 100 milliseconds (See storage.journal.commitIntervalMs)

mongo 默认 60s chekpoint 落盘一次，检查点间的数据有 jounal 保证，启动时会重放 jounal。jounal 默认 100ms 落盘一次

也就是说按照演示一虽然会丢失数据，但是并不肯能轻易的模拟出来（毕竟 50ms 完成数据插入并杀死节点，这手速我不相信是能手动模拟出来的，还能百分百复现）

不搞数学的汤老师
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
mongodb集群问题记录
Haidi_Elisa的专栏
06-16 534
【客户端访问错误】 如果客户端访问的是副本集中处于“SECONDARY”位置的服务，则会提示出现如下错误： 原因： 默认副本集的SECONDARY节点不允许读写 解决方式： （1）访问”PRIMARY”节点； （2）修改slaveOK为true：在客户端执行命令rs.slaveOk()。   【创建唯一索引失败】 为表创建了一个唯一索引，结果仍然可以插入索引字段值重复的记录。
PoGoEncTool:追踪PokémonGO Legality数据为json
03-06
将神奇宝贝GO Legality数据作为json跟踪，并可以输出为PKHeX Legality Binary（pkl），有时也称为pickle。 仅Windows（winforms） 更新json： 生成程序（需要.NET 5，是的！）。 将json从Resources文件夹拖到...
读取MongoDB最新入库数据时，数据丢失
Know_nothing_的博客
01-16 967
实时读取MongoDB增量写入数据时发现数据缺失
mongodb丢失数据的原因剖析
热门推荐
迎风飘来的专栏
03-10 2万+
1.之前用mongodb数据的时候，有时候会有丢失，一开始考虑到是mongodb的安全性能不行吗，在网上看了一些资料，做了一些解释： MongoDB确实在其发展的过程中，有一些数据持久化的问题没有处理好，特别是一些默认值的选定上。大部分用户会拿来就用，直到遇到问题之后才发现他们应该在开始的时候做一些必要的配置。但是，所有这些已经被发现的问题也好，默认设置也好，已经在 MongoDB 2.6以后得
ubuntu mongo数据库无缘无故丢失了？如何保护mongoDB的数据。
在路上
09-29 1584
前两次在ubuntu上部署了mongo 数据库后，分别在docker 和 宿主机上都部署过一次，但是两次的数据都“无缘无故”被丢失了。后来通过查看mongoDB的log (mongo默认log路径： /var/log/mongodb/mongod.log)，可以看到 后来分析到，因为在部署mongodb数据库时，没有对其进行账号密码的设置，导致被黑了，安全意识不够导致的。 解决方法 给mongod数据库设置账号以及密码。 use admin db.createUser( { user: "admin",
Mongodb数据丢失解决办法
qq_45722512的博客
12-19 4421
mongodb数据重启后消失了
MongoDB的数据恢复与备份
最新发布
xiaocxyczh的博客
09-01 1507
本文介绍了MongoDB的数据恢复与备份原理，包括使用mongodump命令备份数据、复制集和分片集群的备份原理，以及使用mongorestore命令和编程代码进行数据恢复的实现。备份分片集群时，可以逐个备份分片服务器上的数据，或对每个分片执行mongodump命令进行备份。在MongoDB中，备份和恢复数据是一项关键任务，可以确保数据的安全性并防止意外数据丢失。以上示例代码使用Java驱动程序连接到MongoDB，备份指定集合的数据并保存到文件，然后从文件中读取数据并恢复到MongoDB中。
mongo-cluster-compose:使用Docker组成mongodb集群
03-31
使用Docker创建Mongo集群 设置副本同步延迟 // local/mongo/init-cluster.js // ... cfg . members [ 1 ] . slaveDelay = 30 ; //seconds // ... 复制模式 创建堆栈 sh stack.sh build 破坏堆栈 sh stack.sh ...
mongo集群说明文档
10-30
《mongo集群部署》这篇文章所需要的配置文件以及mongo压缩包和说明文档
构建BaaS云数据（CloudData）服务—mongo集群架构设计
02-26
任何一个App都需要一个Server，我们认为，移动开发者（或组织）不应该把精力放在这些事情上面：1.搭建后端Server服务；2.编写后端Server代码；3.设计Server底层数据存储架构；4.关注Server的高可用、可扩展、负载...
一段mongo数据库数据丢失 引发的血案
weixin_34336526的博客
11-07 329
2017年1月8日上无，一个晴朗的早上（大周末的晴朗的早上），我还在梦境中，被一个电话吵醒，众所周知，做运维的最怕在休息期间接到公司同仁电话！ 起因：同事说线上的某个功能不能用了！（这个功能就是在mongo数据库中获取数据返给前端进行渲染） 经过：之前也出现过类似的问题，排查故障后是因为mongo实例挂掉（某种原因造成），这次没想到事情比之...
MongoDB数据丢失（即无法写入）的原因
Present
11-23 1万+
从Mysql导出数百万条数据到MongoDB，然而跑了一半多之后发现虽然Mysql的查询仍是正常进行的，但MongoDB中的数据不再增加了，不过java也没抛出异常。表面上看一切正常，但MongoDB已经无法写入了。 首先需要解决的一个问题是把错误打印出来，默认情况下是无法打印出错误而是继续执行的，所以首先将collection.insert(DBObject)改为collection.inser
数据查询和业务流分开_复盘领英Hadoop数据丢失事故，我们得到的血泪教训
weixin_39606003的博客
11-21 123
作者 | Sandhya Ramu，Vasanth Rajamani 译者 | 核子可乐 策划 | 蔡芳芳 复盘在 LinkedIn 发生的数据丢失事件，我们认识到：对企业而言，失败往往比成功更具有启发性。其次，如果团队行动太快，又无法以完全透明的方式处理问题，那么失败所带来的影响有可能长期困扰团队。 我们发生了数据丢失的严重事件：在部分机架中，约有 2...
mongodb集群部署（副本集）踩坑
ぃ高小莫博客
07-21 438
mongodb集群部署详细说明
mongodb使用几天，数据库数据突然就消失了，恢复了初始状态
YanHSama的博客
04-26 1308
mongodb数据库丢失
【运维心得】mongodb数据诡异丢失[已解决]
知止不殆
05-16 8741
mongodb数据诡异丢失事件发生原因分析解密时刻深刻教训 事件发生 5月13日17:20左右，接到用户报告，应用的数据丢失，数据全部恢复到最初始的状态。 由于此应用是docker部署在K8S平台，首先查询了一下mongodb容器的日志，发现在17:10左右有一次容器重启。 mongodb容器采用了“有状态负载”的部署，所以有一块持久化的Volume，部署在A节点，当时不是很担心。 后来运维报告，...
MongoDB 默认写入关注保存数据丢失问题与源码简单分析
weixin_33957648的博客
10-31 396
MongoDB 默认写入关注可能保存数据丢失问题分析 问题描述： EDI服务进行优化，将原有MQ发送成功并且DB写入成功，两个条件都达成，响应接收订单数据成功，修改为只有有一个条件成功就响应接收数据成功。只要发送MQ成功，就代表数据已经给下游客单系统，保存DB数据失败可以接受，优先保证数据不阻断。发送MQ失败，保存DB数据成功，代表我们已经接受到订单数据，可以通过容错服务...
为什么MongoDB会丢数据
longxibendi的专栏
10-08 1万+
from: http://nosqldb.org/topic/53f310590d6e869123593428 MongoDB 丢数据的说法已经出现很久很久了，传言甚多。这里简单总结下场景。 1.在MongoDB很早的版本，2.0之前，没有journal,加上默认不是安全写，系统一宕机就可能出现数据丢失，因为数据没有刷盘，也没有恢复日志恢复机制。这个问题倒默认启用journal以及
MongoDB 事务与数据落盘
weixin_38597669的博客
07-10 1656
本文主要总结了MongoDB事务的隔离性和持久性的原理。
BaaS云数据服务：Mongo集群架构深度解析
“构建BaaS云数据（CloudData）服务—mongo集群架构设计，作者赵静，专注于分布式计算、云存储的云数据架构设计。” 在本文中，我们将深入探讨BaaS（Backend as a Service，后端即服务）云数据服务，特别是以mongo...
评论 1
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值