从 mongodb slave 删除 system.profile 集合答案

【问题标题】：Dropping system.profile collection from mongodb slave从 mongodb slave 删除 system.profile 集合
【发布时间】：2016-10-26 09:35:09
【问题描述】：

据此：https://docs.mongodb.com/manual/administration/analyzing-mongodb-performance/#database-profiling，每个副本集都有不同的 system.profile 集合。我正在尝试使用以下方法从其中一个副本中删除 system.profile 集合：

> rs.slaveOk()
> db.setProfilingLevel(0)
> db.system.profile.drop()
2016-10-12T06:42:29.187+0000 E QUERY    [thread1] Error: drop failed: { "ok" : 0, "errmsg" : "not master", "code" : 10107 } :
_getErrorWithCode@src/mongo/shell/utils.js:25:13
DBCollection.prototype.drop@src/mongo/shell/collection.js:739:1
@(shell):1:1

我不确定这里出了什么问题。

【问题讨论】：

如果你输入db.getProfilingStatus()会怎样？
我可以轻松更改分析状态。 db.setProfilingLevel(0) 将分析级别设置为 0。

标签： mongodb

【解决方案1】：

drop 命令失败，因为节点未处于“主要”状态。一个drop collection命令是一个写操作；只允许在主节点上进行写操作。

删除“system.profile”集合的最简单方法是将集合放在主节点上。 drop 命令将被复制到其他节点；可以在 oplog 中看到 drop 命令的条目：

$ db.oplog.rs.find()
....
{ "ts" : Timestamp(1477445036, 1), "h" : NumberLong("1583532073473005081"), "v" : 2, "op" : "c", "ns" : "stack.$cmd", "o" : { "drop" : "system.profile" } }

您可能遇到的问题可能是在执行 drop 命令时在辅助节点上启用了分析的结果。

如果您尝试在启用分析的情况下删除“system.profile”命令，则删除命令将失败并显示错误：

$ db.system.profile.drop()
2016-10-25T18:28:43.030-0700 E QUERY    Error: drop failed: {
    "ns" : "stack.system.profile",
    "nIndexesWas" : 0,
    "ok" : 0,
    "errmsg" : "turn off profiling before dropping system.profile collection",
    "code" : 20
}
    at Error (<anonymous>)
    at DBCollection.drop (src/mongo/shell/collection.js:620:15)
    at (shell):1:19 at src/mongo/shell/collection.js:620

可以在主节点上禁用分析，从而允许执行 drop 命令。但是，如果仍然在辅助节点上启用分析，则 drop 命令的复制将失败并且集合仍然存在。来自 mongodb.log 文件：

2016-10-25T17:46:02.123-0700 W REPL     [repl writer worker 15] repl Failed command { drop: "system.profile" } on stack with status IllegalOperation turn off profiling before dropping system.profile collection during oplog application

这将导致一种奇怪的状态，因为该集合不会存在于主节点上，但会存在于辅助节点上。在辅助节点上禁用分析并尝试再次删除命令不会删除集合；对不存在的集合的 drop 命令本质上是一个 no-op，它不会创建 oplog 条目并且不会被复制。

需要在主节点上创建一个新的“system.profile”集合，然后可以将其删除，从而允许在其他节点上复制和删除命令：

2016-10-25T18:18:18.093-0700 I COMMAND  [repl writer worker 15] CMD: drop stack.system.profile

有问题的节点是否符合 Primary 条件？您可能需要考虑启动故障转移并将节点提升到主状态。这将简化删除此集合的过程。

Marco 也是正确的：以独立状态重新启动有问题的节点也将允许删除集合。然后可以将节点重新插入到副本集中。

【讨论】：

我验证了 db.getProfilingLevel() 在所有节点上返回 0。然后在主节点上创建了一个新的 system.profile 集合。之后，我从主节点中删除了 system.profile 节点，但该更改并未传播到辅助节点。无论如何，我通过强制每个节点一个一个成为主节点然后单独删除 system.profile 集合来解决这个问题。
你检查drop复制失败的节点的日志了吗？它可能会提供一些关于为什么收藏没有被删除的信息。是否有可能在您检查的数据库中禁用了分析，但仍然在存在 system.profile 集合的数据库上启用了分析？
是的，日志中没有任何内容。另外我认为其他数据库上没有启用分析。

【解决方案2】：

我不确定，但如果您需要在副本集中的辅助节点上执行一些通用维护操作，请查看文档：

您需要停止辅助
在不同端口上以独立方式重新启动辅助节点
执行您需要的操作
作为副本集的成员重启 mongodb

这些是更改辅助 (link to documentation) 上的 system.profile 集合大小所需的步骤，因此我假设删除相同的集合应遵循相同的说明。

【讨论】：

有什么理由需要停止辅助？我可以轻松地将 system.profile 放在主节点上。 system.profile 也是一个有上限的集合，所以我什至不能从中删除文档。
这就是我在文档中找到的在副本集的辅助节点上执行一些常规维护的内容，因此我假设删除和重新创建 system.profile 集合应该遵循相同的过程。我没有开发 MongoDB，所以我的回答是基于我从文档中看到的。也许，由于辅助节点上的系统集合在某种程度上与主节点相关，因此应该有某种“保护”来防止 后院更改。