☰

副本集问题发生后，Mongo 守护进程重新启动

tag-icon • tag-icon mongodb
副本集问题发生后，Mongo 守护进程重新启动

我们最近在副本集（2 个读取节点；1 个写入节点）中进行了一次选举，从而改变了主节点。出于好奇，我开始查看日志以了解发生了什么。

看来 mongoNode2 无法与 mongoNode3 通信。当两个节点都无法通信时，看来这会导致 mongoNode2 和 mongoNode3 上的服务重新启动，最终导致在服务重新启动后出现新的主节点。

Thu Jun 23 08:27:28 [ReplSetHealthPollTask] DBClientCursor::init call() failed
Thu Jun 23 08:27:28 [ReplSetHealthPollTask] replSet info mongoNode3:27017 is down (or \
    slow to respond): DBClientBase::findOne: transport error: mongoNode3:27017 query: { \
    replSetHeartbeat: "myReplSet", v: 3, pv: 1, checkEmpty: false, from: \
    "mongoNode2:27017" }
Thu Jun 23 08:27:29 got kill or ctrl c or hup signal 15 (Terminated), will \
    terminate after current cmd ends
Thu Jun 23 08:27:29 [interruptThread] now exiting
Thu Jun 23 08:27:29 dbexit:

mongo 服务是否因 DBClientCursor::init call() 失败而重新启动？这是一个已知错误吗？

需要注意的是，mongoNode2 和 mongoNode3 是同一台 VMware 主机上的虚拟机。MongoNode1 不在同一台主机上，并且它没有遇到任何服务问题。但是，我没有收到有关 VMware 主机上其他虚拟机出现问题的其他报告。

答案1

是的。在 client/dbclient.cpp 中有一个uassert()调用，这很可能导致进程重新启动。其根本原因是在 replSet 代码检查心跳时发生的传输错误（在 中调用了断言findN()）。

这里的代码似乎与我三月份签出的代码和 Github [1] 中当前的代码有很大不同，因此当您在 JIRA [2] 中提交错误报告时，请包含您的版本信息。

MongoDB 的错误跟踪系统中有几个类似的报告，但似乎没有其他人提供足够的信息。

[1]https://github.com/mongodb/mongo/blob/master/client/dbclient.cpp

[2]https://jira.mongodb.org/secure/Dashboard.jspa

相关内容