mongodb事务主备切换失败的根本原因是clientsession仅绑定原主节点内存且不持久化，新主无session上下文致nosuchsession（251）错误；retrywrites对事务控制命令无效，应用层须新建session、幂等重放全部操作。
事务上下文绑定原主节点内存，切换后新主查不到 session
MongoDB 事务失败的根本原因不是“事务被丢弃”，而是 ClientSession 对象只存在于原主节点的内存中，不持久化、不同步。新主节点上根本没有该 sessionID 的任何记录，所以后续调用 commitTransaction 或 abortTransaction 直接报错：NoSuchSession（错误码 251）。
常见现象包括：
WriteCommandError: { "code": 251, "codeName": "NoSuchSession", "errmsg": "No session with the given id" }- 事务卡在
inProgress状态，重试commitTransaction仍失败 - 应用未处理错误，直接抛出异常或超时
retryWrites=true 对事务本身无效，只保单文档写操作
retryWrites=true 是个常被误解的配置：它只对单文档写命令生效（如 insertOne、updateOne），但对 startTransaction、commitTransaction、abortTransaction 这类事务控制命令完全不起作用。
这意味着：
- 事务内任意一步失败（比如主切发生在
updateOne后、commitTransaction前），整个事务就中断了 - 驱动不会自动重试事务块，也不会把未提交的事务“迁移”到新主节点
- 即使连接串写了
retryWrites=true，也必须配合幂等操作 + 应用层重试逻辑才能兜住业务
应用层重试必须新建 session，不能复用旧 session
一旦发生 TransientTransactionError 或 UnknownTransactionCommitResult，你无法“续跑”原事务。每次重试都必须走完整流程：
- 调用
session.endSession()（尤其在连接池场景下防泄漏） - 新建
ClientSession，再调用session.startTransaction() - 重新执行全部读写操作 —— 读要带
readConcern: "snapshot"，写必须幂等（例如用updateOne(, { upsert: true })替代insertOne） - 不要捕获错误后仅重试
commitTransaction()，那会触发NoSuchTransaction
副本集连接配置错误会让主从切换根本不会发生
如果 PyMongo 或其他驱动连副本集都识别不了，主从切换就只是纸上谈兵。最常见问题是连接字符串漏掉 replicaSet 参数：
- 错误写法：
"mongodb://node1:27017,node2:27017,node3:27017/"（没带?replicaSet=my-rs） - 结果：驱动当三台单机用，不发
ismaster探测，不监听拓扑变化，写永远打向第一个地址 - 验证方法：连上后执行
client.admin.command("ismaster")，看返回里是否有"hosts"字段且包含多个节点
真正容易被忽略的是：即使参数全对，PyMongo 的心跳发现和状态更新也有延迟，应用必须能容忍几秒内的临时不可写，并正确响应 NotWritablePrimary 或 InterruptedDueToReplStateChange 错误。
