选举期写操作必然失败，因无主节点导致notwritableprimary等错误，timeoutms和retrywrites均无效，须业务层捕获错误并实现指数退避重试，同时优化读写策略与法定人数配置。
写操作在选举期必然失败，不是超时配置能绕过的
选举期间没有主节点，insertOne、updateOne 等写请求会直接返回 NotWritablePrimary 或 InterruptedDueToReplStateChange，而不是卡住等响应。这不是驱动 bug，也不是网络问题，是 MongoDB 副本集协议的硬性约束：没有多数派共识，就不允许写入。
常见错误是把 timeoutMS 调大（比如设成 30000），以为能“扛过选举”。结果只是让客户端在无主状态下空等，拖长整体延迟，还可能阻塞线程池或连接池。真正该做的是快速失败，把控制权交还业务层处理。
-
timeoutMS控制的是整个操作生命周期：选节点、建连接、发命令、等响应——选举中连主节点都找不到，根本发不出命令 - 即使配置了
retryWrites=true，选举期间的写也**不会重试**；只有成功连上新主后，后续请求才可能触发自动重试 -
maxTimeMS完全无关：它是发给服务器的指令，要求 mongod 中断执行中的查询/聚合，但选举时命令都还没发出去
客户端必须自己实现重试逻辑，不能依赖驱动自动兜底
MongoDB 驱动默认不为选举失败做业务级重试。Java 驱动设 retryWrites=true 只对已路由到可写节点后的临时失败（如网络抖动、锁冲突）生效；Go 驱动的 ContextDeadlineExceeded 错误也不会自动重放请求。
你得在应用代码里捕获明确的选举相关错误，并决定重试策略：
- 识别关键错误码：
NotWritablePrimary、InterruptedDueToReplStateChange、PrimarySteppedDown - 避免无脑重试：同一请求在 500ms 内连续失败 3 次，应降级（如写本地缓存、发消息队列异步落库）
- 重试间隔建议用指数退避：
100ms → 300ms → 800ms，避免雪崩式打到刚选出的新主 - 注意事务场景：跨文档事务在选举期会直接中断，
session.abortTransaction()必须显式调用
readPreference 和 writeConcern 配置不当会放大中断感知
很多业务中断感比实际更严重，是因为读写策略没配合选举窗口做适配。
读场景下，如果连接字符串里硬编码了 readPreference=primary，那选举期所有读也会失败；而其实大部分报表、列表页完全可以接受从节点的最终一致性数据。
写场景下，writeConcern={w: "majority"} 虽安全，但新主选出后还要等多数节点同步完 oplog 才返回——这会让写延迟从几百毫秒拉长到几秒，尤其在跨地域副本集上。
- 读请求建议按需设置：
readPreference=secondaryPreferred（优先读从，主不可用时 fallback 到主） - 普通业务写用
w: 1足够；强一致性场景再升w: "majority"，但要评估延迟代价 - 确认驱动没全局覆盖
readPreference：Spring Boot 的spring.data.mongodb.read-preference会覆盖 URI 中的设置
electionTimeoutMillis 不是你该调的参数，重点检查法定人数是否满足
选举失败的根因几乎从来不是心跳超时太长，而是副本集无法凑出多数派投票。比如 3 节点集群里 2 个挂了，剩下 1 个节点永远选不上主——这时调小 electionTimeoutMillis 没用，它只会让故障判定更快，但解决不了“票数不够”的事实。
真正要查的是 rs.status() 输出里的 health 和 statestr：
-
health: 0表示节点失联，先看网络、防火墙、DNS；不是所有down都是宕机，可能是心跳包被丢 -
statestr: "STARTUP2"或"RECOVERING"说明节点在追 oplog，不是选举问题，而是数据同步卡住了 - 仲裁节点（arbiter）
votes: 1但priority: 0，它只参与投票，不存数据；2 数据节点 + 1 仲裁是最低可用组合
法定人数（quorum）算错是最隐蔽的坑：节点设了 votes: 0 或 hidden: true，表面在集群里，实际不计入投票总数。
