是否可以修改MongoDB oplog并重播它?
一个bug导致更新应用于比预期更多的文档，覆盖了一些数据。数据从备份中恢复并重新集成，因此实际上没有任何丢失，但我想知道是否有一种方法可以修改oplog以删除或修改违规更新并重播它。
我对MongoDB内部没有深入的了解，所以信息丰富的回答，"你不明白它是如何工作的，它是这样的"也将被考虑接受
应用程序或人为错误数据损坏的一个大问题是，对主服务器的错误写入将立即被复制到从服务器。
这就是用户利用"slaveDelay"的原因之一——一个以固定的时间延迟运行您的一个次要节点的选项(当然，只有当您在比次要节点上的延迟短的时间内发现错误或bug时，它才会对您有所帮助)。
如果您没有这样的设置，您必须依靠备份来重新创建您需要恢复到bug前状态的记录的状态。
在数据的独立副本上执行所有操作-只有在验证所有内容都正确地重新创建之后，才能将正确的数据移动到生产系统中。
需要能够做到这一点的是备份的最近副本(假设备份是X小时前的)，并且集群上的oplog必须保存超过X小时的数据。我没有指定哪个节点的oplog，因为(a)副本集的每个成员在oplog中具有相同的内容，(b) 不同节点成员上的oplog大小可能不同，在这种情况下，您想要检查"最大"的oplog。
假设你最近的备份是52小时前的，但幸运的是你有一个oplog，可以保存75小时的数据(耶)。
您已经意识到所有节点(主节点和辅助节点)都有"坏"数据，因此您要做的是将这个最近的备份恢复到一个新的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
现在您需要找到"违规"操作。您可以在oplogR/oplog上使用bsondump命令将oplog转储为人类可读的形式。Bson文件(然后使用grep或其他工具来查找"坏"更新)。或者，您可以通过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
这将从oplog中恢复每个操作。
在oplogR目录中的bson文件在具有ts值的条目之前停止。回想一下，您在单独的实例上执行此操作的原因是这样您就可以验证恢复和重放创建的正确数据-一旦您验证了它，您就可以将恢复的记录写入实际主服务器中的适当位置(并允许复制将更正的记录传播到次要服务器)。