问题标签 [wiredtiger]

我正在迁移到 mongo 3.2 以使用wiredtiger。以前，我通过查看目录中的 dbfile 名称并仅上传我在 s3 上没有的内容来备份到 s3。

这不是有线老虎的选择。文件名与我的数据库名称并没有明确的关系。增量备份wiredtiger db的最佳方法是什么？

我有带有 mmapv1 引擎的 mongodb 3.0.7。现在我想升级到有线触发器。我的操作系统 (OS) 是 Windows server R2 2012。谁能提供升级 Mongo DB Engine 的详细步骤？

提前致谢 ：-）

我正在使用 Mongo DB 2.6，现在我已将 Mongo DB 升级到 3.2 版本。现在它正在使用大量的 RAM 大小。请有人解释一下什么是

1. mongod --inMemorySizeGB
2. mongod --WiredTigerCacheSizeGB

以及如何分配值。当我尝试分配值时，我得到了错误

我需要控制 Mongo DB 的内存使用情况，有什么办法吗？

在研究如何检查 MongoDB 的大小时，我发现了这条评论：

请注意，dbstats 在运行时会阻塞您的数据库，因此它不适合在生产环境中使用。https://jira.mongodb.org/browse/SERVER-5714

查看链接的错误报告（仍处于打开状态），它引用Mongo 文档的话说：

命令需要一些时间来运行，通常是几秒钟，除非 .ns 文件非常大（通过使用 --nssize）。在运行其他操作时可能会被阻止。

但是，当我检查当前的 Mongo 文档时，我没有找到该文本。相反，他们说：

运行命令所需的时间取决于数据库的总大小。由于该命令必须触及所有数据文件，因此该命令可能需要几秒钟才能运行。

对于使用 WiredTiger 存储引擎的 MongoDB 实例，在不正常关闭后，collStats、dbStats、count 报告的大小和计数统计信息可能会减少多达 1000 个文档。要恢复集合的正确统计信息，请对集合运行验证。

这是否意味着WiredTiger存储引擎通过保持持续的统计信息将其更改为非阻塞调用？

我在本地机器上使用 Robomongo。Robomongo 正在使用有线老虎存储引擎来存储我的数据库。现在，当我想将我的数据库复制到我正在使用的远程机器上时：

有线老虎存储引擎正在创建未知的 .wt 格式，因此上述命令无法复制数据库。

在复制空数据库时，正在远程机器上创建。

我可以在 WiredTiger 存储引擎中配置 MongoDB 3.0.0 引入的哪个配置选项的 cacheSizeGB 的最小数量是多少？

表示cacheSizeGB的个数必须是整数？我可以用像 15.5 这样的浮点数来配置它吗？

我无法从 MongoDB 官方文档中找到详细信息。

其中一个集合具有带有字段的文档"sc":[float]。我想迭代所有文档并将其更改为"sc": float，即删除数组并将浮点值直接分配给键。

WiredTiger 会附加所有更新的文档，而不是尝试像 MMap 那样进行一些就地更新，这不是真的吗？

这基本上会使数据库的大小增加一倍，最初的一半是过时的数据。

我需要打电话mongod -repair来丢弃那些过时的文件，还是我需要做其他事情？

我正在使用 MEAN Stack 制作一个 Web 应用程序，但我遇到了版本控制问题。

我正在尝试推送到 Github Enterprise 上的存储库，并且由于我的 WiredTiger 文件的“明显”大小 （您可以在此处看到）

我收到此错误：

远程：错误：文件数据/db/journal/WiredTigerPreplog.0000000002 为 100.00 MB；这超出了 GitHub Enterprise 的文件大小限制 100.00 MB

无论如何配置这些文件以保留更少的“明显”空间？

从 ext4 恢复已删除文件的最佳/最快/最安全方法是什么？

眼镜：

• 磁盘为 1TB SSHD（混合 HDD + SSD），分区也使用 LUKS 加密（版本 1）加密
• Mongodb 使用 WiredTiger 作为存储引擎。

另外，如果我管理文件的部分恢复，我可以对 mongo 的集合进行部分恢复吗？

谁能提供有关如何解决我在使用 mongo 时遇到的零星缓慢问题的见解，或者根据我的缓慢操作日志指出任何明显的问题？

我有 Mongo v3.2.6，使用安装在运行 ubuntu 服务器 14.04 的 m4.large（8GB Ram，2 个虚拟内核）ec2 实例上的 WiredTiger 引擎。在同一台服务器上安装了一个 java 进程，它使用许多线程从/向 mongo 进程读取/写入。没有副本集（我知道应该有），没有我可以看到的内存问题，但是，我一直在遇到无法诊断的零星慢查询。

以下是 2016 年 6 月 21 日的完整日志，其中显示了一些非常长的查询（10 多秒），查询通常在几毫秒内完成。

缓慢的查询似乎总是update或insert操作。上述慢查询表的一个集合是company.token，它有大约 55k 文档，平均大小为 160B。非常频繁地读取此集合（大约每 15 秒突发高达每秒 100 次）。读取查询使用主_id键进行搜索，因此它命中了主键索引。

日志中的另一个集合company.count包含约 270 万个文档，平均大小为 587B，并且写入非常频繁（每 15 秒每秒插入约 100 次突发）。该集合具有针对集合执行的稳定聚合读取查询（也显示在日志中），每分钟几十个。聚合读取match子句命中复合索引，并且扫描的文档似乎永远不会多于返回的文档（executionStats显示在底部）。插入查询往往完成得非常快，每次插入大约需要 1-4 毫秒，但是，每天一次或两次 mongo 似乎会占用 10 有时 20 秒才能完成其他快速操作。

我对延迟的最佳猜测是来自日志中两个集合的高并发写入和读取，但是，我的印象是 WiredTiger 在文档级别使用了意图排他锁和意图共享锁，这应该允许高并发。

最后一点是，我有时会看到另一个仅包含一个文档的集合需要 10 秒才能更新，因此看起来写入和读取队列可能在全局或数据库级别已达到极限。有什么方法可以确认吗？