排查MongoDB副本集选举问题,需搜索Startinganelection、Electionsucceeded、becameprimary三类关键词。注意连续Notsteppingdowndueto、多个Electionsucceeded但无becameprimary、term明显低于其他节点等异常。用journalctl或grep按UTC对齐日志分析。
Starting an election、Election succeeded、became primary 这三类,比从头翻完整日志快得多。优先盯着 INFO 和 WARN 级别,DEBUG 里信息太杂容易干扰判断。每行日志开头的 UTC 时间戳和节点 host 名必须一起看,不同机器的日志如果靠本地时区对齐很容易出错,建议统一转成 UTC 比较,或者用 journalctl -u mongod --since "2026-07-06 14:00:00" --until "2026-07-06 15:00:00" 拉取窗口内的所有节点日志再做人工对齐。
Not stepping down due to,说明该节点卡在旧 term 里,很可能已经失联或无法参与多数派投票。
- 同一时间点多个节点都输出 Election succeeded,但没一个真正 became primary,大概率是网络分区引发了脑裂苗头。
- 某节点重启后日志里的 term 明显低于其他节点(比如别人是 15,它报 9),说明 local.replset 集合数据过期,需要检查 sync 状态或手动干预。
term 是 Raft 协议里的逻辑纪元标识,只保证单调递增,不保证每次 +1。同一 term 内最多只允许一个 primary,且不可回退。它存在每个节点的 local.system.replset 集合里,但日志里反映得更实时。
_electionId 是 ObjectId 类型的临时令牌,仅在本次选举周期内有效,不是节点的身份 ID。同一个节点多次参选,_electionId 必然不同;不同节点在同一 term 内发起选举,_electionId 也不同。
- 如果两个节点日志里出现相同 _electionId,基本可以断定存在严重的时钟漂移、容器镜像复用或日志被篡改。
- primary 当选后会在心跳响应中携带自己的 _electionId,secondary 收到后会记录在 lastHeartbeatRecv 附近,可以用来交叉验证主从视角是否一致。
- 别拿 _electionId 做监控指标——它的生命周期短、无序、不可预测;真正稳定的锚点只有 term + 节点角色 + 时间戳。
rs.status() 或 db.command("replSetGetStatus") 返回的结果里,members[n].stateStr 和 members[n].lastHeartbeat 是判断节点是否真实参与选举的关键字段。
- stateStr: "STARTUP2" 或 "RECOVERING" 的节点,即使出现在配置里,也不会参与投票。
- lastHeartbeat 距离当前超过 heartbeatTimeoutSecs(默认 10 秒),该节点会被视为失联,不计入多数派计算。
- 如果 members[n].electionTime 是空值,或者远早于最近一次 Starting an election 日志的时间,说明该节点根本没收到新选举请求。
cat /var/log/mongodb/mongod.log,滚动日志加多节点场景下容易漏信息。推荐组合使用:
- 实时跟踪:journalctl -u mongod -f | grep -E "(Starting an election|Election succeeded|became primary)"
- 查指定窗口:tail -n 10000 /var/log/mongodb/mongod.log | grep -A 2 -B 2 "Starting an election"(-A/-B 向前后各带 2 行上下文)
- 跨节点比对:把三台机器日志按 UTC 时间重命名后,用 awk '{print $1,$2,$3,$NF}' *.log | sort -k1,2 快速排序查看时间线演进。
真正难的不是找单条日志,而是把散落在不同机器、不同滚动策略、不同时区下的日志按毫秒级对齐。这时候,term 跳变却没有对应的 became primary,或者多个节点同时声称自己 win,才是最需要盯住的信号。
侠游戏发布此文仅为了传递信息,不代表侠游戏网站认同其观点或证实其描述