MongoDB 报 Transaction numbers are only allowed：先确认事务拓扑

应用开始 MongoDB 多文档事务，第一次读写就报 Transaction numbers are only allowed on a replica set member or mongos，应先确认连接的是 standalone、复制集成员还是 mongos。连接成功和普通 CRUD 能执行，都不能证明这套部署支持事务。

下面针对自建 MongoDB。Standalone 不支持多文档事务；当前部署要求应按所用服务器版本核对，本文采用当前文档中的多节点复制集路径。给连接字符串补一个 replicaSet 参数，不会把单独运行的 mongod 自动转换成复制集。

先确认应用真正连接到哪个服务

核对应用生效的连接配置、服务地址、端口与运行版本，并查看服务器实际加载的配置文件和启动日志。Windows 服务可能加载另一个 mongod.cfg；Docker、systemd 或托管启动器也可能覆盖手工修改的文件。不要只看磁盘上存在一个 replication 段就判断服务已经进入复制模式。

已有管理权限的复制集环境可查看成员状态与复制集配置，确认实际名称、主节点及其他成员。状态命令因权限不足失败，不能单独证明服务器是 standalone。应用若通过代理或旧地址连到了另一实例，也要先修正目标，而不是修改正确的那台数据库。

如果确实是 standalone，这个错误的处理重点是部署能力，不是密码编码、authSource 或增大连接池。已经使用复制集或分片集群却仍报错时，应继续核对实际连接路线、服务器版本和驱动使用方式，不能对现有集群重新初始化。

转换要保留原数据与安全配置

将有数据的 standalone 转换成复制集涉及服务重启和拓扑变化，应安排维护窗口。先保存数据库备份、原配置、服务启动参数、现有用户权限与恢复步骤，并确认备份可用于所需的恢复范围。停写期间仍可能有定时任务或后台工作进程，应一并控制。

保留正确的 storage.dbPath 和日志路径。把配置换成一个新目录，会让服务看起来“正常启动但数据没了”；这不是事务支持修好了。也不要把网上的最小示例替换成整份生产配置，原有绑定范围、TLS、认证和资源限制都要继续核对。

配置 replication.replSetName 只是启动复制模式的一部分。按照目标版本支持的步骤初始化复制集、添加其他成员，再确认成员健康与主节点状态。复制集名称应与客户端期望的名称一致。不要把初始化后暂时只有一个主节点的阶段，当作完整的多节点部署已经完成。

转换过程中若服务启动失败，先读当前 mongod 日志的具体错误。配置文件语法、服务账号读取权限、路径、成员认证或名称验证，都可能阻止启动；原来的事务错误不能解释所有新的启动故障。

客户端认证与成员认证是两件事

已开启 authorization 的部署，还需要按目标版本配置复制集成员之间的内部认证。应用用户名和密码用于客户端访问，不自动承担成员互认。

选择合适的内部认证机制，保证各成员身份配置一致，且服务账号能读取所需文件。生产环境应按当前安全要求评估 X.509 等机制；开发测试若使用 keyfile，也要保留权限和分发范围。Unix 对 keyfile 的权限要求不能直接照搬为 Windows 的 chmod 操作，Windows 仍需正确限制文件访问与确认服务账号可读。

成员间和应用到成员间需要可达的地址，但这不要求把 bindIp 改成任意地址或关闭防火墙。使用规划好的 DNS 主机名，核对它们从成员和客户端网络都能解析、连接，并维持所需 TLS 与访问规则。

不要通过关闭 authorization 解决启动，再让原服务长期暴露。若认证流程需要调整，按已有用户和平台的受控迁移步骤处理；已有管理员用户时，也不能期待 localhost 例外自动让所有初始化操作免认证。

复制集就绪后，再调整应用连接

让驱动按复制集拓扑连接，使用实际复制集名称和可达的种子节点，并保留原来的 authSource、认证机制与 TLS 设置。驱动还可能发现并访问配置中公布的其他成员，因此“种子地址能连上”不足以证明发现过程完整。

directConnection 只改变客户端发现和连接方式，不会创建复制集，也不会增加 standalone 的事务能力。不要用它掩盖成员地址不可达或复制集名称不匹配；生产环境应把规划的成员访问路径配置正确。

代码中的事务还需使用正确的 session，相关操作属于同一事务。部署转换解决的是服务器能力边界，不保证应用原有的事务调用、读偏好和异常处理都正确。后续若出现权限、成员选择或事务提交错误，按新的证据继续处理，避免重新改密码或无条件重试未知结果的写入。

恢复后验证数据和事务，再开放写入

先确认原数据库和用户仍在、成员状态与主节点符合规划、应用按预期拓扑连接。在隔离数据中检查正常事务提交，以及中途失败时多文档修改确实一起回滚；不要用真实余额或订单制造失败测试。

成功标准包括原有安全设置有效、数据路径正确、成员访问正常，以及应用不再出现同一事务拓扑错误。只看到 mongod 服务运行或单次普通插入成功，还不足以结束验收。

需要回退时，先控制写入并核对转换以来的新数据与复制状态，再按保存的恢复方案处理。不要在已有新写入后只删 replSetName，或随意恢复旧快照覆盖数据。恢复部署与恢复业务数据是不同步骤，应由能够核对两者状态的维护人员完成。