是否可以修改MongoDB oplog并重放它?
一个错误导致更新应用于比预期更多的文档,覆盖一些数据.数据从备份和重新集成中恢复,因此实际上没有丢失,但我想知道是否有办法修改oplog以删除或修改有问题的更新并重播它.
我没有深入了解MongoDB内部的知识,因此,"你不明白它是如何工作的,它就像这样"的信息性答案也将被考虑接受.
Asy*_*sky 101
应用程序或人为错误数据损坏的一个重大问题是,对主数据库的违规写入将立即复制到辅助数据库.
这是用户利用"slaveDelay"的一个原因 - 一个选项以固定的时间延迟运行您的一个辅助节点(当然,如果您发现错误或错误的时间短于中学的延迟).
如果您没有这样的设置,则必须依靠备份来重新创建需要恢复到其bug前状态的记录的状态.
在单独的数据独立副本上执行所有操作 - 只有在验证所有内容都已正确重新创建后才能将更正的数据移动到生产系统中.
能够执行此操作所需的是备份的最新副本(假设备份是X小时),并且群集上的oplog必须保存超过X小时的数据.因为(a)中的副本组的每一个成员都有在OPLOG和相同的内容我没有指定哪个节点的OPLOG(B)这是可能是您的OPLOG大小是不同的节点成员不同,在这种情况下,要检查"最大的".
所以,假设你最近的备份是52小时,但幸运的是你有一个oplog,可以保存75个小时的数据(yay).
您已经意识到所有节点(主节点和辅助节点)都有"坏"数据,因此您要做的是将此最新备份恢复为新的mongod.在这里,您可以将这些记录恢复到违规更新之前的状态 - 然后您可以将它们移动到当前主服务器中,从而将它们复制到所有辅助服务器.
在恢复备份时,通过以下命令创建oplog集合的mongodump:
mongodump -d local -c oplog.rs -o oplogD
将oplog移动到自己的目录,将其重命名为oplog.bson:
mkdir oplogR
mv oplogD/local/oplog.rs.bson oplogR/oplog.bson
Run Code Online (Sandbox Code Playgroud)
现在你需要找到"冒犯"的操作.您可以使用bsondumpoplogR/oplog.bson文件上的命令将oplog转储为人类可读的形式(然后使用grep或what-not来查找"错误"更新).或者,您可以通过shell中的命令use local和db.oplog.rs.find()命令查询副本集中的原始oplog .
您的目标是找到此条目并记下其ts字段.
它可能看起来像这样:
"ts" : Timestamp( 1361497305, 2789 )
请注意,该mongorestore命令有两个选项,一个调用--oplogReplay,另一个调用oplogLimit.您现在将在已恢复的独立服务器上重播此oplog但您将在此违规更新操作之前停止.
该命令将是(主机和端口是新恢复的备份的位置):
mongorestore -h host --port NNNN --oplogReplay --oplogLimit 1361497305:2789 oplogR
这将从oplogR目录中的oplog.bson文件恢复每个操作,该文件在具有ts值Timestamp(1361497305,2789)的条目之前停止.
回想一下,您在单独的实例上执行此操作的原因是,您可以验证还原并重播创建的正确数据 - 一旦您验证了它,您就可以将还原的记录写入真实主数据库中的适当位置(并允许复制传播)更正的记录到次要的).
| 归档时间: |
|
| 查看次数: |
23558 次 |
| 最近记录: |