如何查看MongoDB副本集选举日志
快速定位选举日志应直接搜索“Starting an election”“Election succeeded”“became primary”三类关键词，优先查看INFO/WARN级别日志，结合UTC时间戳与节点host名比对，避免时区混淆；发现相同_electionId、term异常或多个节点同时声称当选，需警惕脑裂、时钟漂移或数据过期。
怎么快速定位选举日志行
直接搜 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 和 _electionId 到底怎么看
term 是 Raft 协议里的逻辑纪元标识，只保证单调递增，不保证每次 +1；同一 term 内最多一个 primary，且不可回退。它存于每个节点的 local.system.replset 集合中，但日志里更实时。
_electionId 是 ObjectId 类型临时令牌，仅在本次选举周期内有效，不是节点身份 ID。同一个节点多次参选，_electionId 必然不同；不同节点在同一 term 内发起选举，_electionId 也不同。
- 发现两个节点日志里出现**相同**的
_electionId，基本可断定存在严重时钟漂移、容器镜像复用或日志被篡改 - primary 当选后会在心跳响应中携带自己的
_electionId，secondary 收到后会记在lastHeartbeatRecv附近，可用于交叉验证主从视角是否一致 - 别拿
_electionId做监控指标——它生命周期短、无序、不可预测；稳定锚点只有term+ 节点角色 + 时间戳
用 replSetGetStatus 查状态时注意什么
rs.status() 或 db.command("replSetGetStatus") 返回的结果里，members[n].stateStr 和 members[n].lastHeartbeat 是判断节点是否真实参与选举的关键字段。
-
stateStr: "STARTUP2"或"RECOVERING"的节点，即使出现在配置里，也不会参与投票 -
lastHeartbeat距离当前超过heartbeatTimeoutSecs（默认 10 秒），该节点会被视为失联，不计入多数派计算 - 如果
members[n].electionTime是空值或远早于最近一次Starting an election日志时间，说明该节点根本没收到新选举请求
Linux 下查日志的实操命令组合
别只依赖 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，才是最需要盯住的信号。
