E11000重复键错误'是您在恢复过程中可能遇到的错误。在本博客中,我们将讨论在什么情况下为PITR(时间点恢复)恢复Oplog时可能会遇到这种错误。

您可能想知道为什么在PITR期间会出现这个错误,因为Oplog中的操作是幂等的,这意味着无论执行多少次,它们总是导致对数据库的相同更改。现在让我们看看在应用Oplog时,在哪种情况下可能会遇到这种错误。

我创建了一个集合有四个具有唯一复合索引的文档。因此,根据应用程序逻辑,首先插入、更新和删除文档,但是当重新插入新文档时,将使用创建唯一索引的相同键和值创建新文档。

指数:

对象中插入、更新、删除并再次插入具有相同值的文档的方式编写了应用程序逻辑数量而且作者在其上创建唯一索引的键。下面我们已经插入了四个文档,现在,我们将更新下面的一个文档。

  1. 首先插入:


    Oplog中对应的操作:
  2. 后更新:


    Oplog中对应的op:

  3. 删除后:


    Oplog中对应的op:

  4. 下面我们将插入一个新文档:


    Oplog中对应的op:

  5. 以database london的mongodb为例:

  6. 我们将再次插入一个新文档:


    Oplog中对应的op:

  7. 采用增量式Oplog备份。

    第一次Oplog转储后:


    上面是第一次Oplog备份的最后一个文档,即till{" $时间戳":{“t”:1679561151,“我”:2}}

    第二次Oplog转储(增量)后:

    上面是第二次/增量Oplog备份的开始文档,即:美元的时间戳”:{“我”,“t”:1679561151:3}}

  8. 删除数据库:

    Oplog中对应的op:

  9. 首先,我们将从所接收的转储中恢复数据库第五步

    上述恢复的文件匹配直到第五步在转储伦敦数据库之前:

    从dump恢复后,Oplog中对应的操作:

  10. 现在,我们将检查Oplog备份数据已恢复到哪个文档,以及我们需要从哪个Oplog文件应用ops。我们可以看到第一个Oplog备份中的文档已经在第9步中恢复。为了验证,下面是第一次Oplog备份中的最后一个ops条目:

    现在我们需要在drop命令ops之前重放第二次Oplog备份(我们在第8步中已经有了drop database命令的时间),用于PITR(我们可以看到下面的ops已经可用,但我们不能根据时间或ops分割BSON文件,所以我们需要应用完整的Oplog切片):

    我们可以看到Oplog重放由于唯一的索引约束而失败,因为我们可以看到与的操作相关联{数字:4.0,作者:“Graham”}已经存在于数据库中:

    下面是来自与之关联的增量Oplog备份片的操作{数字:4.0,作者:“Graham”}.所以如果你看到下面的第一个操作是一个带有不同_id的插入操作(“o”:{" _id ": {" $ oid”:“641年c11c1d0495f80ac5e610f"})这是在开头插入的。当Oplog尝试重放下面的操作时,它看到已经有一个文档具有不同的_id{数字:4.0,作者:“Graham”},由于唯一的索引违反,它不能应用此操作。因此未能应用Oplog和PITR。

以上问题有两种解决方案:

    1. 如果增量Oplog备份只有从数据库备份中的最后一个操作开始的操作。
    2. 雷竞技下载官网MongoDB的Percona备份(PBM)配置,并让PBM自动处理所有上述手动过程(恢复转储+为PITR应用Oplog)。

为了克服上述问题,我配置了PBM在相同的副本集上,并进行了备份(包括完整和增量Oplog)。这是如何安装、设置和配置PBM

下面是我从第1步到第6步再一次执行PBM的过程,下面是Oplog中对应的操作:

下面是两个完全备份+增量Oplog备份:

上面,你可以看到最新的备份被采取直到2023 - 03 - 23 t12:14:08进行增量Oplog备份直到2023 - 03 - 23 - t13:06:45。

现在我们将删除数据库:

现在我们将恢复数据库并使用PBM执行PITR:

下面是还原+ PITR的日志:

以下是通过PBM恢复+ PITR后的文件:

下面是PBM恢复后的Oplog条目,我们可以看到PBM首先恢复了相关的基本备份,并在基本备份中的最后一个操作之后开始应用Oplog。


在上面,您可以看到PBM应用了最新的备份并自动执行了PITR。我们没有面对的原因是E11000重复键错误在使用PBM的PITR期间,PBM自动处理它,它需要从其中的Oplog条目应用从完全备份恢复后的操作。在恢复完全备份+增量Oplog备份时,PBM将确保一致性。

这是如何Pe雷竞技下载官网rcona备份MongoDB工作

结论

上面,我们可以看到如何使用PBM自动避免“E11000重复键错误”。另一种方法也是可能的,如上所述,但这将需要手动过程。当PBM是开源的,不需要任何许可证,并且可以自动处理时,为什么要使用手动流程呢?

请查看我们的产品雷竞技下载官网MongoDB的Percona服务器雷竞技下载官网MongoDB的Percona备份,雷竞技下载官网MongoDB的Percona操作符.我们也推荐你去看看我们的博客MongoDB:当开源已经覆盖时,为什么要为企业付费?

雷竞技下载官网Percona Distribution for MongoDB是一个免费提供的MongoDB数据库替代方案,为您提供了一个单一的解决方案,它结合了来自开源社区的最佳和最重要的企业组件,并进行了设计和测试,以协同工作。

现在就下载Mong雷竞技下载官网oDB的Percona发行版!

订阅
通知的
客人

1评论
最古老的
最新的 大多数投票
内联反馈
查看所有评论
理查德。

You had me really hoping — but I’m using PBM to restore automatically and I’m seeing that exact duplicate key error when restoring my database, which had no collection or database drops I’m running out of ideas on how to fix it.