直接看\_electionId和term可判断选举异常、胜者及脑裂风险，但须结合日志时间线与节点角色；单独看数字无意义。
直接看 _electionId 和 term 就能判断选举是否异常、谁赢了、有没有脑裂风险——但必须结合日志时间线和节点角色一起读，单独看数字毫无意义。
怎么从 mongod 日志里快速定位选举事件
副本集选举触发时，所有参与节点都会在日志中输出带 "Starting an election" 或 "Election succeeded" 的行，关键字段就藏在附近：
- 搜索关键词：
"Starting an election"、"Election succeeded"、"StepDown"、"became primary" - 优先看
INFO或WARN级别日志，DEBUG级别太杂，容易漏重点 - 注意每条日志开头的时间戳（UTC）和节点 host 名，不同节点的日志必须对齐时间才能比对
term演进 - 如果看到连续多条
"Not stepping down due to..."，说明有节点卡在旧term里没同步上，可能已掉出多数派
term 不是递增整数，而是“逻辑纪元”标识
term 是 Raft 协议里的核心概念，代表一次“领导权周期”。它不保证严格 +1，只保证单调递增；同一 term 内最多一个 primary，且不可回退。
- 正常选举：旧 primary 主动 stepDown → 所有节点 bump
term到新值（比如从5→6）→ 投票开始 - 网络分区时：两边各自 bump
term（如 A 区到7，B 区也到7），但因无法凑够多数票，谁都成不了 primary —— 这就是潜在脑裂信号 - 节点重启后读到的
term若明显低于其他节点（比如别人是12，它还报8），说明它长期失联，状态文件（local.replset）已过期，需手动干预或等待 sync -
term存在local.system.replset集合里，可用db.getSiblingDB("local").system.replset.findOne()查，但日志里更实时
_electionId 是临时令牌，不是身份 ID
_electionId 是每次选举启动时生成的 ObjectId，作用是在本 term 内唯一标记这次投票行为。它不跨 term 有效，也不代表节点身份。
- 同一个节点多次参选，
_electionId一定不同；不同节点在同一term内发起选举，_electionId也不同 - 如果发现两个节点日志里出现了**相同**的
_electionId（极罕见），基本可断定日志被篡改或存在严重时钟漂移/容器镜像复用问题 - primary 成功当选后，会在心跳响应中携带自己的
_electionId；secondary 收到后会记录在lastHeartbeatRecv附近，可用于验证主从视角是否一致 - 不要试图用
_electionId做监控指标——它生命周期短、无序、不可预测，term+ 角色 + 时间戳才是稳定锚点
真正难的是把散落在三台机器、不同时区、不同滚动策略下的日志按毫秒级对齐；term 跳变但没对应 "became primary"，或者多个节点同时声称自己 win 了同一 _electionId，这种时候得立刻查网络连通性和时钟同步状态——日志数字本身永远不说谎，但它们只回答“发生了什么”，不解释“为什么发生”。
