事务中断后无法自动重试，因事务生命周期绑定单个mongod实例；正确做法是启用retryWrites=true处理单文档写操作，事务失败需应用层幂等补救。
事务执行中发生主从切换，绝大多数情况会直接报 InterruptedDueToReplStateChange 或 NotMasterNoSlaveOk 错误，事务自动中止 —— 这不是 bug，是 MongoDB 副本集的正常行为。靠手动重试事务逻辑既不可靠也不推荐，正确解法是启用 retryWrites=true 并确保驱动和服务器版本兼容。
为什么事务不能自动重试？
MongoDB 的多文档事务（session.startTransaction()）本身不支持跨节点重试：一旦事务在 Primary 上启动，后续所有操作必须路由到同一节点；若该节点在事务中途 stepDown，整个事务上下文丢失，服务端无法恢复状态。
- 事务生命周期绑定单个 mongod 实例，不跨选举延续
-
retryWrites=true仅对单文档写操作（如insertOne、updateOne）生效，对commitTransaction或abortTransaction无效 - 即使驱动捕获到
NotMaster，也无法安全地把未提交的事务“搬”到新 Primary 上继续
Retryable Writes 能覆盖哪些场景？
retryWrites=true 是客户端连接字符串或选项里配的开关，它只对满足条件的单文档写命令起作用 —— 和事务无关，但能显著降低因主从切换导致的写失败感知。
- 生效前提：MongoDB 3.6+ 服务端 + 驱动支持（如 Node.js 3.0+、Python PyMongo 3.6+）
- 仅重试幂等写操作：
insertOne、updateOne、deleteOne、replaceOne、findOneAndUpdate等（不含updateMany） - 触发条件：收到
NotMaster、NodeNotFound、ShutdownInProgress等拓扑类错误时，驱动自动换节点重发请求 - 注意：
retryWrites不影响读操作，读负载需靠readPreference控制（如设为primaryPreferred）
事务中断后该怎么补救？
事务失败后没有“续跑”机制，只能由应用层判断状态并决定是否重放业务逻辑 —— 但必须避免重复执行副作用。
- 关键原则：事务外维护幂等标识（如订单号 + 状态机），用
findAndModify或唯一索引约束防止双写 - 不要在 catch 块里无条件重试整个事务块，容易造成数据不一致
- 典型模式：先查最新状态（
findOne({ orderNo: "xxx" })），再决定是跳过、修正还是新建 - 如果事务内含外部调用（如支付回调），必须拆出事务，用本地消息表 + 补偿任务兜底
最容易被忽略的配置点
很多人开了 retryWrites=true 却没生效，问题常出在连接初始化阶段或版本错配。
- 连接字符串里必须显式加参数：
mongodb://host1,host2/?retryWrites=true&replicaSet=rs0（缺replicaSet参数会导致驱动降级为 direct connection 模式，retryWrites失效） - Java 驱动需确认
MongoClientSettings中retryWritesEnabled为 true，且未被 Builder 链中其他设置覆盖 - PyMongo 4.x 默认启用
retryWrites，但若连接的是单节点（非 replicaSet），它会静默禁用 —— 可通过client.topology_description检查当前 topology 类型 - 事务失败日志里若出现
TransientTransactionError，说明服务端识别出这是可重试事务错误，但客户端仍需自己处理，它不会自动重试
