我阅读了有关
oplog的信息，并意识到开发某种东西来重播日志非常容易，但是事实证明我并不需要像mongorestore那样为我做这些。 br />现在我有一个使用bash脚本的可行解决方案，这很容易，这就是我在这里询问我的逻辑是否存在缺陷的原因，或者将来可能会困扰我的原因。完整备份过程
锁定写入辅助成员
db.fsyncLock() 拍摄快照
从oplog记录最后一个位置
db.oplog.rs.find().sort({$natural:-1}).limit(1).next().ts
解锁写
db.fsyncUnlock() 增量备份过程
锁写o不存在次要成员
从已记录的oplog位置转储oplog到完整（或最新的增量）备份上：
mongodump --host <secondary> -d local -c oplog.rs -o /mnt/mongo-test_backup/1
--query '{ "ts" : { $gt : Timestamp(1437725201, 50) } }'
记录最新oplog位置（与完全备份相同）
解锁写入
完整的备份还原过程
全部停止
mongod的实例将快照复制到将是主要磁盘的数据目录中，但请确保排除所有
local*和mongod.lock，此恢复技术称为通过破坏镜像来重新配置启动主服务器
重新配置副本集
启动没有任何数据的辅助服务器，让它们执行初始同步。或使用新的
local数据库从新主数据库复制数据还原增量备份
创建增量备份时，它像这样存储它：
/mnt/mongo-test_backup/1/local/oplog.rs.bson
/mnt/mongo-test_backup/1/local/oplog.rs.metadata.json
已在
oplog.rs.bson上插入，但我们必须将其重命名，因此步骤如下：将目录更改为备份：
cd /mnt/mongo-test_backup/1/local 删除json文件
rm *.json 重命名bson文件
mv oplog.rs.bson oplog.bson 恢复它：
mongorestore -h <primary> --port <port> --oplogReplay /mnt/mongo-test_backup/1/local
我已经编写了所有脚本，可以稍后在GitHub上提交。
问题是，是否存在任何缺陷逻辑？我有点怀疑，因为该过程非常简单，但仍然找不到任何地方的文档。
#1 楼
回答您的问题。没有！您的逻辑没有失败，它应该可以正常工作。但是，如果可以使用LVM快照，则是进行备份的更好方法。评论
如何对LVM快照进行增量备份？谢谢！
– TanisDLJ
17年4月4日在12:56
LVM快照本质上是增量的。快照是及时的时刻，仅记录更改。
–JJussi
17年4月4日在13:54
只是快照，是的，它是增量的。但是，如果您存档快照，则是完整备份。例如，您不能像重复备份一样归档其他增量备份。而且，您不能简单地每30分钟开始为增量备份创建快照，因为这会严重影响性能。
– TanisDLJ
17年4月4日在14:06
评论
您正在使用哪个版本的Mongo？如果使用的是wiredtiger，那么您用db.fsyncLock（）引用的第一项就是一个问题。 MongoDB Inc声称：“对于WiredTiger，带有lock选项的fsync命令不能保证数据文件不会更改。因此，请不要使用这些方法来确保创建备份的一致性。”链接@SDillon使用3.0.4，但尚未使用WiredTiger，至少现在还没有。我决定使用它，而不是锁写，我们将不得不一起停止mongod。很公平，谢谢
我发现以下用于增量备份的工具github.com/EqualExperts/Tayra希望这会有所帮助
“在版本3.2中进行了更改：带有lock选项的fsync命令可以确保使用MMAPv1或WiredTiger存储引擎的MongoDB实例的数据文件不会更改，从而为创建备份提供了一致性。”
进行增量备份的普通（绝对简便）方法是使用LVM和快照。 docs.mongodb.com/manual/tutorial/…