MongoDB 4.2+跨分片事务提交失败主因是分片间配置或版本不一致，需确保enableMajorityReadConcern启用、小版本（含补丁号）及gitVersion完全相同、w:"majority"写关注满足奇数投票节点要求。
MongoDB 4.2+ 跨分片事务提交失败，90% 以上不是代码问题，而是分片间配置或版本不一致——尤其是 enableMajorityReadConcern 开关、小版本号（含补丁号）、w: "majority" 写关注这三项没对齐。
检查所有分片是否启用 majority read concern
跨分片事务在 prepare 阶段就要求每个分片都能响应 readConcern: "majority"。如果任一分片未启用该特性，mongos 会静默拒绝事务，错误日志里甚至不提 readConcern，只报类似 NotMasterOrSecondary 或 ReadConcernMajorityNotAvailableYet。
- 逐个连接每个 shard 的 primary，执行
db.runCommand({ getCmdLineOpts: 1 })，确认返回中parsed.enableMajorityReadConcern === true - 若用 Docker 或 Kubernetes 部署，检查启动参数是否漏掉
--enableMajorityReadConcern（仅靠配置文件storage.journal.enabled: true不够） - 运行
rs.status()，确保所有成员状态为PRIMARY或SECONDARY，且optimes.lastCommittedOpTime接近主节点；若存在STARTUP2或ROLLBACK状态成员，该分片暂不支持 majority 读
验证各分片 MongoDB 小版本与 gitVersion 是否完全一致
4.2 引入的两阶段提交协议对分片间协调逻辑极其敏感。哪怕只是补丁号不同（如 4.2.20 vs 4.2.18），也可能导致 txnNumber 解析失败、prepare 响应格式错位，最终表现为 UnknownTransactionCommitResult 或 TransactionTooOld。
- 对每个 shard 的 primary 执行
db.version()，比对完整版本字符串（包括补丁号） - 执行
db.runCommand({ buildInfo: 1 })，检查gitVersion字段——同一集群内必须 100% 相同；若出现-dirty后缀，说明是非官方构建，风险极高 - 滚动升级时，必须先升 config server 副本集，再按顺序逐个升级 shard，严禁跳步或混用版本
确认 writeConcern 和副本集拓扑满足 majority 语义
事务提交阶段强制使用 { w: "majority", j: true }，哪怕你在代码里显式设了 w: 1。如果底层不满足 majority 条件，commit 会直接失败，且错误信息模糊。
- 所有分片副本集必须有奇数个投票节点（≥3），否则
"majority"无法达成——仲裁节点（arbiter）不参与数据写入，不能算进 majority 计票 - 检查
rs.conf()中每个成员的votes和priority字段，确保无隐藏的非投票节点干扰 quorum - 禁用内存存储引擎（in-memory）分片：它默认
writeConcernMajorityJournalDefault: false，会导致事务无法提交
事务体本身是否触发路由或集合限制
即使配置全对，事务内操作若违反分片约束，也会在 startTransaction 阶段就被拦截，报 IllegalOp 或 TransactionNotSupported。
- 事务中所有读写操作必须能路由到同一分片：查询/更新条件必须包含完整分片键（如
{ tenant_id: "abc", order_id: 123 }），不能只传前缀或用范围操作（$gt、$in）跨分片 - 事务内禁止操作任何未分片集合（包括
config、local、system.*库，以及虽在分片集群但未执行sh.shardCollection()的集合） -
maxTimeMS在跨分片事务中只控制协调分片上的操作耗时，不保证全程超时；实际耗时取决于最慢分片，别指望靠调大这个值解决根本问题
最容易被忽略的是：enableMajorityReadConcern 必须在每个分片启动时就生效，而不是运行时动态开启；gitVersion 差一个字符，事务就可能在高并发下间歇性失败，且难以复现。
