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 上。有一个符号链接 /var/lib/mongodb/log_db 指向 /dev/sdb1 上的目录。由于日志数据库已满，我们需要升级 /dev/sdb1 的磁盘。

Answer 1

您应该使用带有 --oplog 选项的 mongodump。在同时更新集合的副本集上使用 mongodump 运行完整数据库备份可能无法为您提供一致的备份。随着更大的数据库、更多的集合和更频繁的更新/插入/删除，这种情况会变得更糟。

来自您的 MongoDB 版本 (2.2) 的文档（与 2.6 相同，但尽可能准确）：

--oplog

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

不带--oplog，如果dump过程中有写操作 操作时，转储不会及时反映。变化 在更新过程中对数据库进行的操作会影响输出 备份。

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

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

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

Answer 2

我猜这与 oplog 不够长有关，尽管您似乎检查过它并且看起来相当大。

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