MongoDB 2.2：为什么在转储/恢复后没有复制赶上集合？

Question

我们在Ubuntu 10.04上运行MongoDB 2.2的三服务器复制集，最近必须为每个特定数据库所在的服务器升级硬盘。该数据库包含Web服务请求的日志信息，它们使用当前时间戳在每小时桶中写入集合以确定名称，例如， log_yyyymmddhh

我执行了这个过程：

• 使用 mongodump --db log_db
备份主服务器上的数据库
• 使辅助服务器脱机，更换磁盘
• 以独立模式启动辅助服务器（即注释掉replSet条目 在启动服务之前在/etc/mongodb.conf中）
• 使用 mongorestore --drop --db log_db
还原辅助服务器上的数据库
• 将辅助服务器添加回复制集并将其联机， 让复制赶上更新/创建的每小时桶 当它已经离线时

一切似乎都按预期进行，除了备份 时当前存储桶的集合不是 通过复制更新。我不得不手动手动复制该集合以使其更新。请注意，在备份之后创建的集合已正常同步。

在这个过程中我错过了什么导致MongoDB不能为那个集合恢复同步？我假设有一些关于oplog的问题？

修改1：

主要版本上的oplog显示其最早的时间戳已经过了几天，所以应该有足够的空间来维持几个小时的交易（这是次要离线的时间）。

编辑2：

我们的MongoDB安装使用两个磁盘分区：/ dev / sda1和/ dev / sdb1。主要的MongoDB目录/ var / lib / mongodb /位于/ dev / sda1上，并且包含多个数据库，而日志数据库本身驻留在/ dev / sdb1上。 sym链接 / var / lib / mongodb / log_db 指向/ dev / sdb1上的目录。由于日志数据库已满，我们需要为/ dev / sdb1升级磁盘。

Answer 1

我猜这与oplog的关系不够长，虽然看起来你检查过它看起来相当大。

但是，在将新成员添加到副本集时，您不应该快照并恢复它们。最好简单地添加一个新成员并让复制本身发生。 This is described in the Mongo docs并且是我一直遵循的过程。

Answer 2

您应该将mongodump与--oplog选项一起使用。在同时更新集合的复制集上使用mongodump运行完整数据库备份可能不会为您提供一致的备份。对于更大的数据库，更多的集合以及更频繁的更新/插入/删除，情况会变得更糟。

来自MongoDB版本（2.2）的文档（2.6版本相同，但只是为了尽可能准确）：

  

<强> - OPLOG

     

使用此选项可确保mongodump创建转储   包含oplog的数据库，用于创建时间点快照   mongod实例的状态。恢复到特定时间点   备份，使用与此选项一起创建的输出   mongorestore --oplogReplay。

     

如果没有--oplog，则在转储期间有写操作   操作，转储不会反映单个时刻。变化   在更新过程中对数据库进行的操作会影响输出   备份。

http://docs.mongodb.org/v2.2/reference/mongodump/

大多数关于备份和恢复的MongoDB教程都没有很好地解决这个问题。通常，如果您可以执行数据库所在存储卷的实时快照，那么您会感觉更好（假设您的存储解决方案具有与MongoDB兼容的实时快照功能）。如果做不到这一点，那么您的下一个最佳选择是使辅助离线，然后执行数据库文件的快照或备份。由于性能问题，实时数据库上的Mongodump越来越不是大型数据库的最佳解决方案。

我绝对会看一下备份选项的MongoDB概述：http://docs.mongodb.org/manual/core/backups/