MongoDB Operator 不提供事务开关，事务依赖实例版本≥4.0、副本集部署（非standalone）及正确write concern；Operator仅按规范部署满足前提的副本集。
MongoDB Operator 本身不直接暴露 transaction 开关，事务支持由 MongoDB 实例版本和副本集拓扑决定；Operator 只负责按规范部署符合要求的副本集。只要满足「4.0+ 版本 + 副本集（非单机）+ 正确的写关注（write concern）」，事务就能用。
确认 MongoDB 版本与部署类型是否满足事务前提
MongoDB 4.0 是事务支持的起点，但仅限副本集和分片集群 —— 单机（standalone）模式不支持多文档事务。
-
type: ReplicaSet是硬性要求，members至少为 3（生产建议），不能设为 1 -
version必须 ≥"4.0.0"，推荐使用"6.0.0"或更高（Operator v1.4 已验证支持） - 避免在 spec 中误设
architecture: standalone—— 这会覆盖type，导致 Operator 创建单点 Pod
错误示例（看似是副本集，实则退化为单机）：
spec: type: ReplicaSet architecture: standalone # ← 这行会生效，忽略 type
storage 配置必须匹配底层存储类能力
事务频繁写入 oplog 和 journal，对 IOPS 和延迟敏感。Operator 的 storage 块不定义性能，只声明容量和访问模式，真正起作用的是你绑定的 StorageClass。
-
storage.type: Durable是唯一受支持的类型（Operator 不支持Memory或EmptyDir） -
storage.size推荐 ≥"20Gi"（低于 10Gi 容易触发 journal 切换抖动） - 对应
StorageClass必须支持ReadWriteOnce且开启allowVolumeExpansion: true（后续调大卷需此配置） - 避免使用默认
standard类（如 GKE 默认类基于 HDD），应显式指定高性能类，例如：storageClassName: "gp3-encrypted"
Operator 不校验 StorageClass 是否真实存在或兼容 —— 若指定不存在的类，Pod 将卡在 Pending 状态，事件中提示 Failed to provision volume。
副本集参数里没有 transaction 字段，但有三个关键间接控制点
事务行为由 MongoDB 进程启动参数和客户端驱动共同决定，Operator 通过以下字段影响其基础能力：
-
spec.replicaSetHorizons：空值或未设时，Operator 使用默认心跳间隔（2 秒）。高延迟网络下建议显式设置，避免因心跳超时触发主节点降级，中断正在进行的事务 -
spec.security.tls.enabled: true：事务日志（oplog）复制走网络，未加密时可能被截获；Operator 强制要求 TLS 启用才允许创建跨节点副本集（v1.4+） -
spec.additionalMongodConfig：可注入原生 mongod 参数，例如：{"storage.journal.commitIntervalMs": 50}—— 缩短 journal 刷盘间隔能降低事务提交延迟，但增加磁盘压力
注意：additionalMongodConfig 中的键名必须是 MongoDB 官方支持的配置项，Operator 不做语法校验；写错（如拼成 journal.commitIntervalMS）会导致 mongod 启动失败，Pod 反复 CrashLoopBackOff。
最容易被忽略的点：Ops Manager 与事务无直接关系，但它的存在会影响配置生效路径
如果你通过 Ops Manager（即用 MongoDBOpsManager CR）来管理该副本集，所有事务相关配置仍由 MongoDB 自身控制；但 Operator 会把 spec.configuration 中的参数（如 mms.backup.enabled）同步给 Ops Manager，而 Ops Manager 可能反向下发不兼容的自动化策略（比如强制关闭 journal）。务必确认：spec.configuration.mms.backup.enabled 和 spec.configuration.mms.monitoring.enabled 不会覆盖你手动设置的 journal 或 oplog 行为。
