MongoDB事务在副本集上必须使用w:"majority"写关注才能保证原子性和持久性；单/双节点无法满足多数要求，PSA架构虽技术可行但因仲裁节点不存数据而不推荐用于关键业务；三节点P-S-S是最小安全基线。
MongoDB 事务在副本集上运行时，**必须依赖多数写入确认（w: "majority"）才能保证原子性和持久性**。这意味着：如果副本集节点数不足三，就无法构成“多数”，事务会因无法满足写关注而失败或降级为非事务性行为。
为什么 w: "majority" 是事务的硬性前提
MongoDB 事务的提交阶段要求所有参与操作的日志（oplog）被多数节点持久化，否则可能在故障后丢失已提交的事务结果。单节点或双节点副本集无法定义“多数”——单节点的多数是 1，但无容错；双节点的多数是 2，一旦任一节点宕机，写入即阻塞，事务直接不可用。
-
w: "majority"不是可选配置，而是事务协调器（transaction coordinator）内部强制校验项；驱动程序即使显式设置w: 1，事务提交仍会按w: "majority"执行 - 查看当前写关注是否生效，可用
db.runCommand({getLastError: 1, w: "majority"})测试；返回"ok": 1且无"wtimeout"才表示多数写就绪 - 使用
mongosh连接后执行db.adminCommand({replSetGetStatus: 1})，确认members[n].stateStr全部为PRIMARY或SECONDARY，且ok: 1
选举中断期间事务完全不可用
副本集选举期间（主节点失联 → 心跳超时 → 新主选出），整个集群在 rs.status().members[n].stateStr === "STARTUP2" 或 "RECOVERING" 状态下，**不接受任何写入，事务会立即报错 InterruptedDueToReplStateChange 或 NotMasterNoSlaveOk**。
- 默认心跳超时为 10 秒，选举完成通常需 2–12 秒；这期间所有事务请求被拒绝，而非排队等待
- 应用层不能靠重试绕过——事务上下文（
session.startTransaction()）在连接断开或主节点变更后即失效，必须新建 session - 若使用仲裁节点（PSA 架构），选举虽能更快达成（2票即可），但因仅一份数据副本，事务提交后若主节点宕机且未同步到从节点，仍可能回滚
两节点 + 仲裁节点（PSA）能否支撑生产事务
技术上可以启动事务，但**不推荐用于关键业务**：PSA 架构只有一份完整数据副本，w: "majority" 实际等价于 w: 2（主 + 仲裁），而仲裁节点不存储数据，无法参与 oplog 同步。这意味着：
- 事务日志只落盘在主节点，仲裁节点投票不等于数据确认；主节点崩溃后，未复制到从节点的事务将永久丢失
-
rs.printSecondaryReplicationInfo()显示的optimeDate在 PSA 中对仲裁节点恒为空，无法判断数据同步延迟 - 当主节点宕机，选举出的新主是原从节点，但其 oplog 可能落后于旧主——此时已提交的事务若未同步过去，就会在新主上回滚（rollback）
真正可靠的事务保障，取决于数据是否真实写入多数节点的磁盘。三节点 P-S-S（主-从-从）是最小安全基线：它既满足多数写（3 节点中 2 票），又确保任意单点故障后仍有完整数据副本在线。少一个数据节点，就多一分静默丢事务的风险。
