问题标签 [mongodump]

我有一个包含 3 个成员的副本集。每个都在 Linux 上运行 mongod 2.4.8。我正在使用 MMS 代理来监控我的副本集/主机的运行状况，并且一切正常。

我正在使用 mongodump 备份我的数据库，如果我不使用 --oplog 开关，可以成功转储，如下所示：

mongodump -v --db "mydb" --out /backups

但是，当我备份实时数据库时，我想使用 --oplog 开关。所以我修改了我的命令以包含 --oplog 开关并在 --hosts 开关中指定我的副本集：

mongodump -v --oplog --host myrepset/m1:27017,m2:27017,m3:27017 --db "mydb" --out /backup

但是，此命令失败并出现以下错误：oplog mode is only supported on full dumps

这显然与尝试在单个实例上使用 --oplog 开关时抛出的错误相同。

我已阅读 mongo 教程和参考页面，但不明白我做错了什么。http://docs.mongodb.org/manual/reference/program/mongodump/

非常感谢任何帮助。

我已经使用 mongorestore 来恢复数据库，但是当我尝试运行我的应用程序时，我收到一个错误，即索引已经存在。

我知道函数 db.collection.dropIndex() 但有没有办法自动化这个并立即从数据库中的所有集合中删除所有索引？

我试过了

但这并不能解决问题。有任何想法吗？

我们有一个在 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 的磁盘。

我正在尝试使用mongodump或mongoexport无法正确地将 mongodb 数据从我的服务器导出到本地驱动器。

我试过这些命令： -

和

我收到此错误：-

出了什么问题？

在我的第一台服务器上，我得到：

使用 mongodump/mongorestore迁移此数据库后，在我的第二台服务器上，我得到：

在我等了几个小时后，mongo 完成了索引，我得到了：

我测试了数据库，没有损坏或丢失的数据。

为什么迁移前后大小差异如此之大？

我有一个包含大量数据的 mongodb 实例，现在我需要启动一个具有相同结构但没有数据的新实例。

如何完成？

我正在尝试使用查询进行 mongodump。下面是我的语法。

我想要做的是转储所有embedded_document.field_1不等于的记录Zebra。

我有 100 条记录Zebra，但找到的记录数等于所有记录数 ( 5000)。

该查询在 mongo shell 中运行，它返回正确的计数 ( 100)。

有任何想法吗？

db.stats()我使用 Mongo GridFS，并且我有一个相当大的 Mongo 数据库，当我使用该命令时，当前 dataSize 为 89GB 。

当我创建 mongo 转储时，文件系统中的目录大小为 86GB，当我在另一台机器上恢复数据库并运行时，db.stats()我现在得到 122GB。

有谁知道转储/恢复后数据大小增加 33GB 背后的原因是什么？

编辑 这是来自初始数据库的统计数据

这是来自已恢复数据库的统计信息

以下是对可能原因的一些想法：

1. 出于某种原因，我在恢复的版本中多了 40 个对象！
2. 不同的mongo版本，这可能是索引算法发生变化的原因吗？
3. 初始数据库位于副本集中
4. 最初的数据库曾经是 320 GB，但我进去并压缩了所有图像，不久前将其减少到 75 GB。这就是为什么初始数据库的存储大小要大得多的原因

mongodump 命令：

结果是：

我在用损坏的文档恢复我们的数据库时遇到问题。mongorestore当损坏的文档出来时停止恢复。这是错误。

实际上在备份之前发生了同样的错误。文档被破坏的原因仍然未知（只是猜测可能是意外关闭）。该服务器未使用副本集，并且启用了日志记录。检索损坏文档的.find()命令总是失败。损坏的文档也由.valid()命令识别。但是 mongodb 无法使用db.repairDatabase()and恢复它mongod --repair。我的临时措施是使用 备份数据，然后使用命令mongodump删除损坏的文档。.remove()

现在的问题是如何从备份中恢复完整的数据库以及如何正确修复它。有没有办法在有（或没有）损坏的文档的情况下恢复数据库？

MongoDB版本：2.6.1