【问题标题】:MongoDB replica node become "(not reachable/healthy)"MongoDB 副本节点变为“(不可访问/健康)”
【发布时间】:2021-12-21 21:05:43
【问题描述】:

在我当前的项目中,我们为生产环境中的文档管理服务设置了 3 个节点 MongoDB 副本集(1 个主节点和 2 个从节点)。 由于设置已经存在,因此它运行正常。有一个 REST API 端点将文档上传到 mongo DB。 由于需要对 mongodb 进行一些性能测试,所以我通过 JMeter 启动了负载测试,并创建了一个测试计划,通过模拟 5 个用户将数据直接插入到 mongoDB。

所有三个节点都已启动并运行,短期测试没有任何问题。 但是长时间运行负载测试时,一个节点变为“(不可访问/健康)”并在其他两个节点中选择了新的 PRIMARY,负载测试运行时没有任何问题并使用现有的两个节点插入数据。

在开发环境中,通过删除问题节点并将其添加为新节点确实可以正确同步数据并恢复为辅助节点。 但是由于这些相同的配置存在于生产环境中,我们真的需要知道是什么导致一个节点变为“(不可访问/健康)”。

请注意,在当前系统中,我们没有启用安全性,所有三个节点都运行在具有不同端口号的同一服务器上,配置详细信息如下。

节点 mongodb01

mongod.conf - will be the same for other two nodes with own dbpath, log path and port

会员详情状态:

enter "members" : [
            {
                    "_id" : 2,
                    "name" : "<host>:27018",
                    "health" : 0,
                    "state" : 8,
                    "stateStr" : "(not reachable/healthy)",
                    "uptime" : 0,
                    "optime" : {
                            "ts" : Timestamp(0, 0),
                            "t" : NumberLong(-1)
                    },
                    "optimeDurable" : {
                            "ts" : Timestamp(0, 0),
                            "t" : NumberLong(-1)
                    },
                    "optimeDate" : ISODate("1970-01-01T00:00:00Z"),
                    "optimeDurableDate" : ISODate("1970-01-01T00:00:00Z"),
                    "lastHeartbeat" : ISODate("2021-11-09T05:24:39.870Z"),
                    "lastHeartbeatRecv" : ISODate("2021-11-09T03:07:38.381Z"),
                    "pingMs" : NumberLong(300),
                    "lastHeartbeatMessage" : "Error connecting to <host>:27018 (10.103.58.45:27018) :: caused by :: Connection refused",
                    "syncSourceHost" : "",
                    "syncSourceId" : -1,
                    "infoMessage" : "",
                    "configVersion" : 21,
                    "configTerm" : 106
            },
            {
                    "_id" : 7,
                    "name" : "<host>:27019",
                    "health" : 1,
                    "state" : 1,
                    "stateStr" : "PRIMARY",
                    "uptime" : 498947,
                    "optime" : {
                            "ts" : Timestamp(1636435479, 10),
                            "t" : NumberLong(106)
                    },
                    "optimeDate" : ISODate("2021-11-09T05:24:39Z"),
                    "syncSourceHost" : "",
                    "syncSourceId" : -1,
                    "infoMessage" : "",
                    "electionTime" : Timestamp(1636332442, 1),
                    "electionDate" : ISODate("2021-11-08T00:47:22Z"),
                    "configVersion" : 21,
                    "configTerm" : 106,
                    "self" : true,
                    "lastHeartbeatMessage" : ""
            },
            {
                    "_id" : 8,
                    "name" : "<host>:27017",
                    "health" : 1,
                    "state" : 2,
                    "stateStr" : "SECONDARY",
                    "uptime" : 99236,
                    "optime" : {
                            "ts" : Timestamp(1636435479, 5),
                            "t" : NumberLong(106)
                    },
                    "optimeDurable" : {
                            "ts" : Timestamp(1636435479, 5),
                            "t" : NumberLong(106)
                    },
                    "optimeDate" : ISODate("2021-11-09T05:24:39Z"),
                    "optimeDurableDate" : ISODate("2021-11-09T05:24:39Z"),
                    "lastHeartbeat" : ISODate("2021-11-09T05:24:39.371Z"),
                    "lastHeartbeatRecv" : ISODate("2021-11-09T05:24:39.371Z"),
                    "pingMs" : NumberLong(0),
                    "lastHeartbeatMessage" : "",
                    "syncSourceHost" : "<host>:27019",
                    "syncSourceId" : 7,
                    "infoMessage" : "",
                    "configVersion" : 21,
                    "configTerm" : 106
            }
    ],here

【问题讨论】:

    标签: mongodb testing jmeter load replicaset


    【解决方案1】:

    all three nodes runs in the same server - 非常有趣的设置,你想在这里实现什么?复制和主/从设置的全部要点是绕过single point of failure 约束,在您的情况下,您没有任何好处,只是消耗底层操作系统资源,单个实例正确tuned and optimized 将更快地工作

    看看:

    • MongoDB log files,尤其是对于失败的实例
    • 操作系统日志文件
    • 操作系统性能指标(即 CPU、RAM、磁盘、网络使用情况等),可以使用 JMeter PerfMon Plugin 来完成,因为您的 Mongo 实例之一可能开始消耗大量资源并且已经被OOMKiller终止

    【讨论】:

    • 嗨@Dmitri T,感谢您的输入,请注意,在开发环境中,我们将所有三个节点都设置在同一台服务器上,但我们正在将其迁移到生产中的三个不同的Linux VM。是的,我知道复制在一台服务器中时不会受益。再次感谢我将进一步分析日志,还将获得 Jmeter 插件进行系统分析。在问题节点日志中,我可以看到状态为:"ctx":"ftdc","msg":"serverStatus was very slow"
    猜你喜欢
    • 2013-06-14
    • 1970-01-01
    • 2018-07-27
    • 2023-02-07
    • 1970-01-01
    • 2023-04-03
    • 2022-10-18
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多