MongoDB爱好者
垂直技术交流平台

MongoDB案例分享:如何使用oplog恢复数据

最近跟数据恢复杠上了,这不又来一例。关于备份恢复的问题其实我在6年多以前就写过,其中大部分讨论放在今天仍然适用。

 

1.案例介绍

某用户使用了MongoDB 4.0,数据库中的一个表因为drop操作导致数据全部丢失。但因为库本身很小,而oplog空间足够大,所以从建库至今的所有操作都尚在oplog中没有被回收。基于这种情况,虽然他们没有全量备份,我们仍然可以通过完整重放oplog来找回所有丢失的数据。所以我们的操作是:

  1. 导出oplog
  2. 寻找drop发生的时间戳;
  3. 重放到drop前一刻;
  4. 将恢复的数据dump/restore到生产库;

步骤4属于基本操作就不详细叙述了,主要来看前面3步。

 

2.恢复步骤

2.1 导出oplog

这一步实际上特别简单。oplog位于local.oplog.rs集合中,我们可以使用mongodump直接导出,导出节点可以是主节点或从节点。基本形式是:

mongodump --host <host>:<port> -d local -c oplog.rs -u <user> --authenticationDatabase <adb>

得到如下输出:

> tree dump
dump
└── local
    ├── oplog.rs.bson
    └── oplog.rs.metadata.json

1 directory, 2 files

我们需要的就是oplog.rs.bson

2.2 寻找截止时间戳

进行重放的关键是要先找出重放截止到哪条oplog。这里有两种办法:

方案1

oplog.rs.bson中搜索关键字drop

> bsondump dump/local/oplog.rs.bson | grep drop
{"ts":{"$timestamp":{"t":1646056645,"i":1}},"t":{"$numberLong":"1"},"h":{"$numberLong":"7307295890643732087"},"v":{"$numberInt":"2"},"op":"c","ns":"test.$cmd","ui":{"$binary":{"base64":"9sakiEOMS2qjwBZ5O0mQjQ==","subType":"04"}},"wall":{"$date":{"$numberLong":"1646056645661"}},"o":{"drop":"survey"}}

如果多次出现drop记录,则要自己注意辨别哪条是你想要的那条。然后注意记录中{"t":1646056645,"i":1}是我们要截止到的时间戳,后面将会用到这个数据。
另外注意如果oplog较多时该办法可能会耗时较长。

方案2

local.oplog.rs中查询。这种查询方法通常会比方案1快,但需要在原始系统上运行查询,可能造成一定的负担。如果系统本身压力已经较大,则要注意避开业务高峰期。另外也可以在从节点上执行查询以避开压力最大的主节点。这里要注意的是每个节点上保存的oplog可能不一样多,但一定是一致的。例如,某个节点上的oplog有1,2,3,4,5共计5条,其他节点上可能只有:

  • 2,3,4,5
  • 3,4,5
  • 4,5
  • 5

这种情况通常是由于从节点是后来加进集群里导致的。那么想要查询时,可以使用:

> use local
> db.oplog.rs.find({"o.drop": {$exists: true}}).sort({$natural: -1}).limit(1);
{ "ts" : Timestamp(1646056729, 1), "t" : NumberLong(1), "h" : NumberLong("6882491835596436855"), "v" : 2, "op" : "c", "ns" : "test.$cmd", "ui" : UUID("a98cba5a-066b-46fe-92a9-d122386dba5d"), "wall" : ISODate("2022-02-28T13:58:49.167Z"), "o" : { "drop" : "survey" } }

同样注意Timestamp(1646056729, 1)是我们将要用到的截止时间戳。

2.3 重放oplog

mongorestore本身是用来恢复bson文件的同时顺便重放oplog的。现在我们没有bson要恢复,只有oplog要重放,所以需要点小花招来欺骗mongorestore,那就是用一个空文件夹:

mkdir empty
mongorestore --host <host>:<port> -u <user> --authenticationDatabase <adb> \
  --oplogReplay \
  --oplogFile dump/local/oplog.rs.bson \
  --oplogLimit 1646056729:1 \
  empty/

注意:这里应该在一个新的实例上完成重放操作。
重放完成后,你就拥有了一份截止到drop操作前的完整数据。

 

3.改进方案

上面的步骤虽然可以完成任务,但有些浪费。因为丢失的只有一个表,我们却恢复了整个数据库,消耗了不必要的时间。有没有办法只恢复丢失的那一个表呢?从原理来讲是可以办到的,那就是只重放这个表上的oplog,那么只需要在导出oplog的时候做个过滤就可以办到了:

mongodump --host <host>:<port> -d local -c oplog.rs -u <user> --authenticationDatabase <adb> -q '{"ns": "test.survey"}'

后续步骤没有什么差异,就不再赘述了。但是这样的做法有个bug,那就是事务。我一开始也栽在了这个问题上。事务会把多条操作放在一条oplog里,以此来保证事务的原子性。比如如下事务操作:

var mongo = db.getMongo();
var session = mongo.startSession();
session.startTransaction();
var coll = session.getDatabase("test").getCollection("survey");
coll.insertOne({y: 1});
coll.insertOne({y: 2});
coll.insertOne({y: 3});
session.commitTransaction();

其产生的oplog是这样的:

{
    "ts": Timestamp(1646057834, 1),
    "t": NumberLong(1),
    "h": NumberLong("-2362908976881142089"),
    "v": 2,
    "op": "c",
    "ns": "admin.$cmd",
    "wall": ISODate("2022-02-28T14:17:14.189Z"),
    "lsid": {
        "id": UUID("02ca1f7e-f451-4ec3-946f-cf307c0d03b7"),
        "uid": BinData(0, "47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=")
    },
    "txnNumber": NumberLong(1),
    "stmtId": 0,
    "prevOpTime": {
        "ts": Timestamp(0, 0),
        "t": NumberLong(-1)
    },
    "o": {
        "applyOps": [{
            "op": "i",
            "ns": "test.survey",
            "ui": UUID("04a8b634-4048-48a6-b358-9a879c1a20ed"),
            "o": {
                "_id": ObjectId("621cd969a3a94c2e74b595c5"),
                "y": 1
            }
        }, {
            "op": "i",
            "ns": "test.survey",
            "ui": UUID("04a8b634-4048-48a6-b358-9a879c1a20ed"),
            "o": {
                "_id": ObjectId("621cd969a3a94c2e74b595c6"),
                "y": 2
            }
        }, {
            "op": "i",
            "ns": "test.survey",
            "ui": UUID("04a8b634-4048-48a6-b358-9a879c1a20ed"),
            "o": {
                "_id": ObjectId("621cd969a3a94c2e74b595c7"),
                "y": 3
            }
        }]
    }
}

可见这里的{"ns": "admin.$cmd"}并不在test.survey上,所以上面的过滤办法会把事务产生的数据都排除在外,就会造成一部分数据丢失。解决办法也很简单,修改一下过滤条件:

mongodump --host <host>:<port> -d local -c oplog.rs -u <user> --authenticationDatabase <adb> -q '{"$or": [{"ns": "test.survey"}, {"o.applyOps.ns": "test.survey"}]}'
 

4.结束语

这个案例是个很极端的情况,所以不要想着抄作业,你几乎一定不会遇到相同的场景。但恢复的原理却是相通的,无论何种备份恢复都是“全量”+“增量”的做法,只要你理解了原理,剩下的就是动手尝试而已。

 

关于作者:张耀星

MongoDB中文社区常委会委员,论坛联席主席。

MongoDB公司北亚区首席技术咨询服务顾问。在MongoDB的开发、应用和咨询服务方面,拥有多年的丰富实践经验。

作为MongoDB认证专家,曾经为不同行业的各类大型客户提供过培训、性能调优、架构设计等各类技术及咨询服务,颇得广大客户信任。

赞(5)
未经允许不得转载:MongoDB中文社区 » MongoDB案例分享:如何使用oplog恢复数据

评论 抢沙发

评论前必须登录!