mongodb事务主备切换中断，本质是session绑定原主内存状态且不持久化，新主无上下文致nosuchsession错误；需启用retrywrites=true、幂等操作及驱动自动重试保障一致性。
主备切换期间分布式事务中断，本质是事务上下文与节点强绑定、日志同步存在窗口、状态未全局持久化三者叠加导致的。解决思路不是“续传原事务”，而是让业务在切换后仍能达成一致结果。
核心原则：放弃恢复，转向幂等重试
数据库层（如 MongoDB、GoldenDB、PG）均不支持跨主节点延续事务状态。Session、2PC 协调者、WAL 应用位点等关键信息都驻留在原主内存或本地磁盘，新主无法继承。因此应用必须接受“原事务已终止”，转而保障：同一业务逻辑重复执行不会破坏数据一致性。
- 所有写操作改用 upsert、$setOnInsert、$inc 等幂等语义指令
- 避免 insert + 主键校验类逻辑，改用带唯一条件的 update 或 findAndModify
- 对 sequence、自增 ID 等全局值，使用数据库原生 nextval() 或原子 CAS 操作，禁用应用层缓存+自增
驱动与连接层：启用自动重试机制
依赖客户端驱动内置的容错能力，而非自行封装重试逻辑：
- MongoDB 驱动需开启 retryWrites=true（4.0+ 默认开启），并确保每个操作都传入同一 ClientSession
- Oracle Data Guard 应用连接串中配置 FAILOVER_MODE=(TYPE=SESSION)(METHOD=BASIC)(RETRIES=180)(DELAY=5)
- PostgreSQL 使用 libpq 连接时，设置 options='-c synchronous_commit=on' 并配合 Patroni 的 retry_timeout 参数
架构层：解耦事务边界与切换窗口
把长事务、跨库事务拆成多个短事务+补偿动作，避开切换高危期：
- 采用 TCC 模式：Try 阶段冻结资源并落库，Confirm/Cancel 均为幂等本地事务，主备切换后由定时任务扫描待确认记录驱动完成
- 引入消息队列：主库提交后发可靠消息，下游服务消费并执行本地事务；切换后由死信重投或延迟补偿保障最终一致
- 读写分离场景下，强制将分布式事务路由至主库执行，从库仅承担纯查询，规避备库升主过程中的状态漂移
验证与兜底：切换后主动检查关键状态
切换完成不等于事务安全，需快速验证核心数据链路是否完整：
- 查询 GoldenDB 的 sys_distributed_transaction 表，确认无 state='prepare' 且无 commit_log 的悬挂 XID
- MongoDB 中检查是否存在长时间处于 inProgress 状态的事务（通过 db.currentOp({ "secs_running": { "$gt": 30 } })）
- Oracle DG 切换后立即运行 SELECT MAX(SEQUENCE#) FROM V$ARCHIVED_LOG 对比新旧主归档序列，确认无断点
