正确，MongoDB分布式事务必须运行在三节点及以上副本集上，因w:"majority"强制要求多数节点确认，单/双节点无法满足容错与选举需求，PSA架构虽技术可行但因仲裁节点不存数据而不推荐用于关键业务，三节点P-S-S是最小安全基线。
分布式事务必须运行在三节点及以上副本集上
MongoDB 分布式事务（包括跨集合、跨数据库操作）在副本集上运行时，w: "majority" 是强制写关注，而“多数”要求节点总数为奇数且 ≥ 3。单节点或双节点副本集无法满足该条件：单节点的 w: "majority" 虽语法合法但无容错能力；双节点要求 w: 2，任一节点宕机即阻塞所有事务写入。
常见错误现象：WriteConcernError: { code: 100, errmsg: "majority write concern not satisfied" } 或事务提交时直接抛出 InterruptedDueToReplStateChange。
- 三节点 P-S-S 架构是最小可行基线，所有节点都存数据，故障时能自动选举新主并保留已提交事务
- PSA（主-从-仲裁）架构技术上可通过选举（2票即可），但仲裁节点不持久化数据，事务提交后若主节点宕机且未同步到从节点，仍可能回滚
- 四节点或五节点可提升可用性，但需注意：MongoDB 对可选举节点上限为 7，超过需将部分节点设为
priority: 0或启用hidden: true
分片集群中每个分片也必须是≥3节点副本集
分布式事务跨分片执行时，协调器（mongos）会向每个涉及的分片发起本地事务。如果任一分片是单节点或双节点部署，该分片上的事务阶段就会因无法满足 w: "majority" 而失败，整个分布式事务回滚。
使用场景：比如 sh.shardCollection("db.orders", { orderId: "hashed" }) 后执行跨 orders 和 inventory 集合的事务，两个集合若位于不同分片，则每个分片都必须是合规副本集。
- 可通过
sh.status()查看各分片是否为副本集，以及成员状态是否全为PRIMARY或SECONDARY -
db.adminCommand({replSetGetStatus: 1})在每个分片的 primary 上执行，确认members[n].stateStr稳定且无STARTUP2或RECOVERING - 不要试图用
w: 1绕过——驱动层显式设置无效，事务协调器内部仍强制校验w: "majority"
选举期间事务完全不可用，不是暂停而是直接报错
副本集发生主节点切换时（如网络分区、进程崩溃），集群会进入短暂不可写状态。此时所有事务请求不会排队或重试，而是立即返回错误，例如 NotMasterNoSlaveOk 或 InterruptedDueToReplStateChange。
默认心跳超时 10 秒，选举完成通常耗时 2–12 秒。这期间新建的 session.startTransaction() 会失败；已开启但未提交的事务 session 也会失效，必须丢弃并重建。
- 应用层不能靠简单重试恢复事务上下文——
session对象绑定到原连接和原主节点，断开即作废 - 若使用连接池（如 Node.js 的
mongodb驱动），需确保事务逻辑外层有 session 生命周期管理，而非复用旧 session - 监控建议：告警
replSetGetStatus.members[n].stateStr === "STARTUP2"或连续出现InterruptedDueToReplStateChange错误
配置服务器（config server）也必须是三节点副本集
在分片集群中，配置服务器存储路由元数据，其可用性直接影响分布式事务能否解析分片位置。MongoDB 要求 config server 必须是三节点副本集（不允许仲裁节点），否则 sh.enableSharding() 或后续分片操作会失败。
错误示例：cannot enable sharding: config server must be a replica set with at least 3 members。
- config server 副本集名称固定为
configReplSet，启动时需明确指定--replSet configReplSet - 即使只存元数据，也不能用单节点或 PSA——因为事务提交前需读取最新 chunk 分布，该读取也受
readConcern: "majority"保护 - 硬件可略低于分片节点（如 4核16GB），但必须用 SSD，且禁用 journal 以外的任何妥协
