MongoDB事务必须运行在副本集模式下，因其实现依赖oplog和majority write concern，而单节点容器不生成oplog且无法满足majority写关注，导致startTransaction()报错CommandNotFound。
MongoDB 事务必须运行在副本集（Replica Set）模式下，单节点容器默认不支持事务；直接用 docker run 启动的单实例即使加了 --auth 或挂载配置文件，session.startTransaction() 仍会报错 CommandNotFound: startTransaction。
为什么单节点 Docker 容器无法启用事务
MongoDB 的事务功能底层依赖 oplog 和 majority write concern，这两者只在副本集（或分片集群）中存在。单节点启动时：
-
mongod不生成 oplog（除非显式启用--replSet并初始化） -
writeConcern: "majority"无法满足，事务提交失败 -
rs.status()报错NoReplicationEnabled，db.adminCommand({listTransactions: 1})直接返回命令不存在
必须用副本集模式：docker-compose 中的关键参数
要让事务生效，不是“加个配置就行”，而是整个部署模型必须切换为副本集。以下参数缺一不可：
-
hostname必须显式设置（如mongo1），不能靠默认容器名；否则rs.add("mongo2:27017")解析失败 -
command必须含--replSet rs0，且建议加--bind_ip_all（Docker 内部通信需监听所有接口） - 所有服务必须共用同一个自定义网络（
networks块定义），确保mongo1、mongo2等 hostname 可互相解析 -
healthcheck要用mongosh --eval "db.runCommand({ping:1})"，而不是简单curl localhost:27017—— 后者成功不代表 replica set 已 ready
初始化脚本里必须执行 rs.initiate() 和 rs.add()
官方镜像不自动做副本集初始化，必须通过 entrypoint 脚本控制时机：
- 只允许一个节点（如
mongo1）执行rs.initiate()，否则重复调用报already initialized -
rs.add()必须等其他节点healthcheck连续通过后才执行，否则报NodeNotFound - 成员地址必须写容器内 DNS 名（
"mongo2:27017"），不能写"127.0.0.1:27017"或宿主机 IP - 初始化完成后，任意节点连上都能开启事务：
session = db.getSiblingDB("test").getMongo().startSession(); session.startTransaction()
事务相关参数的实际影响与陷阱
副本集跑起来后，事务行为还受几个隐性参数约束：
-
transactionLifetimeLimitSeconds默认 60 秒 —— 长事务（如批量导入）可能超时，需在/etc/mongod.conf中调高 -
wiredTigerEngineConfigString若设了cache_size过小（如--wiredTigerCacheSizeGB 0.5），高并发事务易触发WT_CACHE_FULL错误 - 使用
mongosh连接时，必须指定--authenticationDatabase admin，否则db.runCommand({listTransactions: 1})权限不足 - 事务内不能跨数据库操作（如
db.collection1.insert()+db2.collection2.update()），会报MultiNamespaceOpError
事务不是开关式功能，它绑定在整个副本集生命周期里；哪怕你只用一个节点做主库，另外两个节点仅 standby，也必须全部健康在线，writeConcern: "majority" 才能成立 —— 这是容易被忽略的硬性前提。
