rs.status()显示"PRIMARY"但写入失败，是因新主未完成initial sync或oplog追赶，lastCommittedOpTime明显落后，需通过optime差值、syncingTo字段及isMaster探测综合判断，而非仅信stateStr。
rs.status()里看到"stateStr": "PRIMARY"但写入失败
这不是节点没选上，而是刚当选的 PRIMARY 还没完成初始同步（initial sync）或 oplog 追赶，MongoDB 会主动拒绝写入，防止数据不一致。此时 rs.status() 中该节点的 stateStr 是 PRIMARY，但 optimes.lastCommittedOpTime 明显落后于其他节点，且 members[n].syncingTo 可能为空或指向已下线节点。
关键判断依据不是状态字符串，而是 lastCommittedOpTime 和 lastAppliedOpTime 的差值：超过 5 秒就说明还没追平。不要依赖 isMaster 返回的 ismaster: true 就认为可写——它只反映选举结果，不反映同步就绪状态。
应用层如何避免往未同步主节点发写请求
驱动不会自动等待同步完成，它只按拓扑发现结果路由。必须让写操作避开“假主”：
- 所有写操作前加轻量探测：
db.runCommand({ isMaster: 1 })，检查返回中hosts数量是否等于预期（如应有 3 个，却只返回 1 个，说明被隔离）；再查primary字段是否与当前连接地址一致 - Java 驱动需启用
heartbeatFrequencyMS=3000并监听ServerDescriptionChangedEvent，当事件中state从CONNECTED变为UNKNOWN或CONNECTING，立即剔除该节点 - Node.js 驱动设置
directConnection=false+appName="my-app"，配合监控topologyDescription.type是否为"ReplicaSetWithPrimary"，而非"ReplicaSetNoPrimary"或"ReplicaSetSharded"
w: "majority" 写入卡住的真正原因
不是网络慢，而是多数派中至少一个节点仍处于 STARTUP2 或 RECOVERING 状态，无法参与 write concern 投票。此时 w: "majority" 会一直等待，直到超时（默认 30 秒）并抛出 WriteConcernFailed 或 NotMaster。
验证方法：在疑似主节点上执行 rs.printsecondaryreplicationinfo()，看各成员 syncedTo 时间是否全部接近当前时间；再查 rs.status().members 中每个成员的 stateStr 和 health，health: 0 或 stateStr: "ROLLBACK" 都会导致 majority 不满足。
临时缓解可降级为 w: 1，但仅限调试——生产环境必须坚持 w: "majority"，否则脑裂恢复后数据回滚风险极高。
为什么强制 reconfig 后新主还是不同步
常见误操作是只调用 rs.reconfig(..., { force: true }) 更新成员列表，却忽略了新配置中 members[n].priority 和 votes 设置不合理。例如把一个刚重装的空节点 priority 设为 10，它会立刻参选并胜出，但因无历史数据，只能走 initial sync，耗时数分钟到数小时（取决于数据量）。
正确做法是：
- 先停掉待加入节点的 mongod 进程，用
mongod --repair恢复本地数据（如有备份） - 启动后不直接加进副本集，先用
rs.addArb("arbiter-host:27017")加仲裁节点凑够奇数，确保现有健康节点能稳定选举 - 等集群稳定、新节点完成 initial sync（
rs.status()中stateStr变为SECONDARY且optime跟上），再调整其priority并移除仲裁节点
initial sync 不可跳过，也没有“加速开关”。唯一可控的是减少 oplog window 压力：确保 storage.journal.enabled: true 且 oplogSizeMB 足够大（建议 ≥ 10% 数据盘容量），否则追赶过程中 oplog 被覆盖，节点只能重做 full sync。
