mongo 一次oplog损坏事故，重建oplog

最新推荐文章于 2026-06-21 13:17:07 发布

原创最新推荐文章于 2026-06-21 13:17:07 发布 · 1.4k 阅读

3 ·

本内容遵循CC 4.0 BY-SA版权协议

Mongo基础专栏收录该内容

3 篇文章

订阅专栏

在一次MongoDB集群事故中，由于并发导致内存消耗过高，引发查询延迟和节点故障。通过定位问题为oplog.rs损坏，采取了重建oplog的措施，包括查找最近的oplog记录、保存记录、删除并重建oplog.rs、调整角色权限、恢复记录，最终解决了延迟问题。

一、集群环境

3个mongos、3个mongo config、3个shard（每个分片各三台，一主两从）

二、事故描述

次数1:某次活动，由于并发太多，导致mongod连接数太多，内存消耗太多（每个连接上来会分配一定的内存空间），导致整体query慢，产生大量堆积（应用报超时等错误）。直接重启mongod，重启前未stepDown，其中一个从节点2发现错误。临时剔除节点，打算后续有时间解决（原因未知）

次数2:此时距离上次事故6天，节点2还未修复。同一个分片主节点1意外出现同样的错误（原因未知）此时只有一个主节点，熬夜紧急修复这两个节点

次数3:距离第二次事故两天，同一个分片主节点3又出现了同样的错误（原因未知）此时一阵冷汗，同一个分片轮番坏了一遍，辛亏解决的及时。

三、解决步骤

1、查看报错信息，感觉像是数据块损坏问题。并且此分片不能做更新操作，但是可以正常查询。

2、问题定位，oplog.rs损坏

> db
> local
  db.oplog.rs.find()
  error: {
          "$err" : "BSONObj size: 1852142352 (0x1073656E) is invalid. Size must be between 0 and 16793600(16MB) First element: Status: ?type=100",
          "code" : 10334
  }

3、重建oplog

1）找到最近的一条oplog记录

> db.oplog.rs.find( { }, { ts: 1, h: 1 } ).sort( {$natural : -1} ).limit(1).next()
{"ts" : Timestamp(1497172747, 46), "h" : NumberLong("4489544342319430008")}

2）保存记录

> db.temp.save(db.oplog.rs.find( { }, { ts: 1, h: 1 } ).sort( {$natural : -1} ).limit(1).next() )
//确认操作，很重要
>db.temp.find()

3）删除oplog.rs，物理文件不会删除

> db.oplog.rs.drop()

4）建立新的oplog

> db.runCommand( { create: "oplog.rs", capped: true, size: (50 * 1024 * 1024 * 1024) } )
{
	"ok" : 0,
	"errmsg" : "not authorized on local to execute command { create: \"oplog.rs\", capped: true, size: 53687091200.0 }",
	"code" : 13
}
//很悲催，重建capped类型的表，显示没权限，而oplog.rs必须要是capped类型，可是已经是root最大权限

将shardsvr角色更改为configsvr角色，去掉keyfile认证（相当于去掉权限），重启服务，再次执行

configsvr> db.runCommand( { create: "oplog.rs", capped: true, size: (50 * 1024 * 1024 * 1024) } );
{ "ok" : 1 }

为什么要更改角色呢？

--因为shardsvr角色，去掉keyfile认证，服务启动不了。哭～～～

5）将上次操作的最近一条记录写到oplog中

> db.oplog.rs.save( db.temp.findOne() )

6）确认操作

> db.oplog.rs.find()
{"ts" : Timestamp(1497172747, 46), "h" : NumberLong("4489544342319430008")}

7）修改配置文件，更改会原来的配置，重启服务。重新加入到集群中。查看延迟状态

rs:SECONDARY> db.printSlaveReplicationInfo();
source: mongod122:10000
	syncedTo: Mon Jun 12 2017 03:11:41 GMT+0800 (CST)
	0 secs (0 hrs) behind the primary 
source: mongod121:10000
	syncedTo: Sun Jun 11 2017 23:52:12 GMT+0800 (CST)
	11969 secs (3.32 hrs) behind the primary

待延时追上后，一切归于正常。