1. 备份和恢复工具参数
* 几个重要参数:
* mongodump
* --polog:复制mongodump开始到结束过程中的所有oplog并输出到结果中。输出文件位于dump/oplog.bson
* mongorestore
* --oplogReplay:恢复完数据文件后再重放oplog。默认重放dump/oplog.bson
=>
* --oplogFile:指定需要重放的oplog文件位置
* --oplogLimit:重放oplog时截止到指定时间点
2. 实际操作:mongodump/mongorestore
为了模拟dump过程中的数据变化,我们开启一个循环插入数据的线程:
```
for(var i = 0; i < 10000; i++) {
db.random.insertOne({x:Math.random() * 100000});
}
```
在另一个窗口中我们对其进行mongodump:
```
mongodump -h 127.0.0.1:27017 --oplog
```
使用mongorestore恢复到一个新集群:
```
mongorestore --host 127.0.0.1 --oplogReplay dump
```
3. 更复杂的重放oplog
假设全量备份已恢复到数据库中(无论使用快照、mongodump或复制数据文件的方式),重要放一部分增量怎么办?
* 导出主节点上的oplog:
* mongodump --host 127.0.0.1 -d local -c oplog.rs
* 可以通过 --query参数添加时间范围
* 使用bsondump查看导出的oplog,找到需要截止的时间点
* 恢复到指定时间点
* 利用--oplogLimit指定恢复到这条记录之前
* mongorestore -h 127.0.0.1 --oplogLimit "1577355175:1" --oplogFile dump/local/oplog.rs<空文件夹>
4. 分片集备份
分片集备份大致与复制集原理相同,不过存在以下差异:
* 应分别为每个分片和config备份;
* 分片集备份不仅要考虑一个分片内的一致性问题,还要考虑分片间的一致性问题,因此每个片要能够恢复到一个时间点;
5. 分片集的增量备份
尽管理论上我们可以使用与复制集相同的方式来为分片集完成增量备份,但实际上分片集的情况更加复杂。这种复杂性来自两个方面:
* 各个数据节点的时间不一致:每个数据节点很难完全恢复到一个真正的一致时间点上,通常只能做到大致一致,而这种大致一致通常足够好,除了以下情况:
* 分片间的数据迁移:当一部分数据从一个片迁移到另一个片时,最终数据到底在哪里取决于config中的元数据。如果元数据与数据节点之间的时间差异
正好导致数据实际已经迁移到新分片上,而元数据仍然仍未数据在旧分片上,就会导致数据丢失情况发生。虽然这种情况发生的概率很小,但仍有可能导致问题。
要避免上述问题的发生,只有定期停止均衡器;只有在均衡器停止期间,增量恢复才能保证正确。
手机扫一扫
移动阅读更方便
你可能感兴趣的文章