0

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

我执行了这个过程：

  • 使用mongodump --db log_db备份主服务器上的数据库
  • 使辅助服务器脱机，更换磁盘
  • 以独立模式启动辅助服务器（即在启动服务之前注释掉 /etc/mongodb.conf 中的 replSet 条目）
  • 使用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 的磁盘。

4

2 回答 2

0

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

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

--oplog

使用此选项可确保 mongodump 创建包含 oplog 的数据库转储，以创建 mongod 实例状态的时间点快照。要恢复到特定时间点备份，请结合使用通过此选项创建的输出和 mongorestore --oplogReplay。

没有--oplog，如果dump操作过程中有写操作，dump不会及时反映一个时刻。在更新过程中对数据库所做的更改可能会影响备份的输出。

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

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

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

于 2014-07-03T00:24:54.093 回答
0

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

尽管如此，当向副本集添加新成员时，您不应该对它们进行快照和恢复。最好简单地添加一个新成员并让复制自己发生。这在 Mongo 文档中有描述，也是我一直遵循的过程。

于 2014-07-02T22:33:12.400 回答