标签: mongodb-3.2

此查询仅扫描一份文档并仅返回一份文档。但这非常慢：

2017-05-22T07:13:24.548+0000 I COMMAND [conn40] query databasename.collectionname query: { _id: ObjectId('576d4ce3f2d62a001e84a9b8') } planSummary: IDHACK ntoskip:0 keysExamined:1 docsExamined:1 idhack:1 cursorExhausted:1 keyUpdates:0 writeConflicts:0 numYields:0 nreturned:1 reslen:42 locks:{ Global: { acquireCount: { r: 2 } }, Database: { acquireCount: { r: 1 } }, Collection: { acquireCount: { r: 1 } } } 8009ms
2017-05-22T07:13:24.549+0000 I COMMAND [conn10] query databasename.collectionname query: { _id: ObjectId('576d4db35de5fa001ebdd77a') } planSummary: IDHACK ntoskip:0 keysExamined:1 docsExamined:1 idhack:1 cursorExhausted:1 keyUpdates:0 writeConflicts:0 numYields:0 nreturned:1 reslen:42 locks:{ Global: { acquireCount: { r: …

在我的 MongoDB 日志中，我看到以下消息行：

2016-04-05T00:03:42.904+0000 I COMMAND  [ftdc] serverStatus was very slow: { after basic: 200, after asserts: 240, after backgroundFlushing: 380, after connections: 510, after dur: 650, after extra_info: 930, after globalLock: 1070, after locks: 1190, after network: 1270, after opcounters: 1310, after opcountersRepl: 1310, after storageEngine: 1430, after tcmalloc: 1620, at end: 2900 }
2016-04-05T00:03:49.910+0000 I COMMAND  [ftdc] serverStatus was very slow: { after basic: 160, after asserts: 220, after backgroundFlushing: 390, after connections: 580, after dur: 670, after …

我必须将 200GB MongoDB 从一台服务器移动到另一台服务器（Windows 2016 操作系统）。在这个操作过程中，假设伴随的程序会离线，所以不需要担心数据不一致，但我需要尽量减少停机时间。磁盘空间不是问题，但停机时间是问题。我曾尝试使用 mongodump 和 mongorestore 对其进行测试，但这花了将近 20 个小时才完成，这看起来很荒谬。我正在考虑其他几个选项：

1. 使用复制数据库
2. 获取磁盘快照和/或将 db 文件夹直接复制到新服务器，并通过更改 .conf 文件中的路径将安装指向该服务器。

我猜 #2 如果它可以工作的话会是最快的，但我还没有找到任何真正的确认它可以在 Windows 平台上工作。有没有人成功做到这一点？如果是这样，是否像我描述的那样简单？如前所述，可以为此操作完全关闭 MongoDB 及其随附的程序。

或者，谁能给我一个大概的数字，说明 copydb 与 mongodump/mongorestore 操作相比需要多长时间？

当我们使用 mongo（Mongo 版本：2.6）将 AEM 6.1 实例升级到带有 mongo（Mongo 版本：3.2）的 AEM 6.3 时，我们面临异常。

org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore 后台操作失败：org.bson.BsonSerializationException：29344731 的文档大小大于最大值 16777216。

DocumentNodestore 如何超过其限制？有没有办法解决这个问题？修订垃圾收集是否会减少 DocumentNodeStore 的大小？

我们正在通过分片将单个 Mongo 实例迁移到 Mongo 集群。我还没有开始分片。但是，我发现当我尝试添加索引时，我无法再查询任何集合。我们当前的 Mongo 实例中没有这个问题。在我们当前的 Mongo 中，我们可以同时应用索引和查询集合。

这是我在新集群上创建索引时运行的命令：

mongos> db.lc_data.ensureIndex({"name": 1})

现在，我打开另一个终端并查询同一数据库中的集合或其他集合。

mongos> db.lc_other.find()

查询将挂起！为什么会出现这种情况？

我将MongoDB (3.2.6)其用作我的应用程序的存储，因为几周后 MongoDB 通常每 1 或 2 周就开始崩溃。崩溃似乎来自WiredTiger内存分配期间的问题，这里是stacktrace上次崩溃的全部内容：

2016-10-09T18:25:36.389+0200 E STORAGE  [thread1] WiredTiger (12) [1476030336:325695][993:0x7f559c19a700], file:index-1108-8065571460375661294.wt, WT_SESSION.checkpoint: memory allocation of 18624 bytes failed: Cannot allocate memory
2016-10-09T18:25:36.547+0200 E STORAGE  [thread1] WiredTiger (12) [1476030336:422567][993:0x7f559c19a700], file:index-1108-8065571460375661294.wt, WT_SESSION.checkpoint: checkpoints cannot be dropped when in-use: Cannot allocate memory
2016-10-09T18:25:37.347+0200 I COMMAND  [conn10793] command admin.$cmd command: ping { ping: 1 } keyUpdates:0 writeConflicts:0 numYields:0 reslen:37 locks:{} protocol:op_query 208ms
2016-10-09T18:25:37.386+0200 E STORAGE  [thread1] WiredTiger (12) [1476030337:254969][993:0x7f559c19a700], checkpoint-server: checkpoint server error: …

我有一个需要重新同步的 MongoDB 实例。

2016-11-07T11:59:23.330+0000 I REPL     [ReplicationExecutor] syncing from: x.x.x.x:27017
2016-11-07T11:59:23.354+0000 W REPL     [rsBackgroundSync] we are too stale to use x.x.x.x:27017 as a sync source
2016-11-07T11:59:23.354+0000 I REPL     [ReplicationExecutor] could not find member to sync from
2016-11-07T11:59:23.354+0000 E REPL     [rsBackgroundSync] too stale to catch up -- entering maintenance mode
2016-11-07T11:59:23.354+0000 I REPL     [rsBackgroundSync] our last optime : (term: 20, timestamp: Oct  4 07:41:29:1)
2016-11-07T11:59:23.354+0000 I REPL     [rsBackgroundSync] oldest available is (term: 20, timestamp: Oct 17 02:13:33:5)
2016-11-07T11:59:23.354+0000 I REPL     [rsBackgroundSync] …

我们最近在 MongoDB 3.2 集群中遇到了与索引创建相关的破坏性事件。设想：

• 使用background: true在主数据库上创建了几个索引。
• 索引是在主数据库上完成后由 MongoDB 在辅助数据库上自动创建的，也是在后台创建的。
• 这最终导致多个后台索引操作在辅助节点上并行运行。到目前为止，一切都或多或少地按预期发生。
• 当 4 个索引器线程最终并行运行时，辅助节点上的所有读取操作似乎都阻塞了（编辑：澄清一下，这甚至包括对未构建索引的数据库的读取操作，根据文档，这甚至不应该发生用于前台构建）。我们使用 secondaryPreferred 选项执行一些读取，这些读取最终完全挂起（见下文）。
• 我们立即中止了进一步的索引创建以及仍在主服务器上运行的后台索引器线程。但是，在所有后台索引线程完成后，辅助节点上的读取操作才开始再次运行。总而言之，我们在 20 分钟内完全无法从二级读取。

什么可以解释这一点，特别是对辅助节点的读取操作最终完全阻塞的事实？索引创建会显着影响性能这一事实众所周知，我们正在考虑这一点。

但是，我们能够找到的文档中没有任何内容解释了在索引创建完成之前完全挂起的二级挂起。我们也无法在主要或次要的日志中发现任何可疑的内容：日志条目仅显示单个索引构建的创建和进度，但没有任何内容可以解释读取操作的阻塞。

这种情况给我们带来了一些重大问题，因为我们使用 Java 驱动程序的 ReadPreference.secondaryPreferred 选项执行某些读取。这些操作没有回退到从主服务器读取，而是在等待辅助服务器时没有超时地挂起，因此在我们的应用程序服务器上迅速建立了一个正在运行（但挂起）请求的大队列。

如果有人能对这种情况有所了解，我们将不胜感激。

技术细节：

• MongoDB 版本：3.2.16（不是最新的，但 .17/.18 更改日志中没有任何内容听起来可能会对此产生影响）
• 引擎：有线老虎
• 资源：主服务器虚拟机和辅助服务器虚拟机均配置有 6 个 CPU 和 128 GB 内存，两者之间有 1 GBit 链接。
• 数据集：约。总共 2 TB，其中约 100 GB 特别活跃。

我想在 mongodb 中使用事务，但它告诉副本集我们可以使用独立的 mongodb 执行事务查询吗？如果是，请分享我们如何做，因为当我尝试它时给出错误

This MongoDB deployment does not support retryable writes. Please add retryWrites=false to your connection string

如何在没有可重试写入的情况下执行翻译。

谢谢

我从未在我的书中看到过这一点，dbpath也没有在搜索引擎中找到任何解释。

我们运行 MongoDB 3.2.8

# ls -alh; pwd
total 151M
drwxr-xr-x. 2 mongod mongod 4.0K Sep 12 22:18 .
drwxr-xr-x. 6 mongod mongod  12K Sep 12 22:16 ..
-rw-r--r--. 1 mongod mongod 8.0M Sep 12 21:54 extsort.0
-rw-r--r--. 1 mongod mongod  10M Sep 12 21:54 extsort.1
-rw-r--r--. 1 mongod mongod 7.9M Sep 12 22:02 extsort.10
-rw-r--r--. 1 mongod mongod 7.9M Sep 12 22:07 extsort.11
-rw-r--r--. 1 mongod mongod 9.9M Sep 12 22:07 extsort.12
-rw-r--r--. 1 mongod mongod 7.9M …

我一直致力于优化对 MongoDB 中大约 200 万个文档的查询，并且我尝试在聚合函数上使用解释，但它会显示

"winningPlan" : {
      "stage" : "EOF"
    },

在此之前，该函数将显示具有“Fetch”等阶段的获胜计划，但在我尝试了几种不同的语法来编写聚合命令之后，它现在显示“EOF”。我试图将我的命令简化为一个find().explain()函数，但它仍然是一样的。任何人有任何想法？

其次，有没有人想出如何进行explain("executionStats")聚合查询。我看到该功能已在此处实现，但是当我运行它时，我得到“EOF”以及基本explain()结果。是不是因为我的 MongoDB 没有更新到 3.5.5？3.5.5 以下的版本是否支持此功能？提前谢谢了。