MongoDB报错‘Cannot $merge to internal database: admin’排查求助

在Unix系统中执行包含多阶段聚合管道的.js脚本，用于提取并合并MongoDB集合数据：

• 自建MongoDB 7.0实例上运行正常，能提取所有预期数据
• 在运维工具管理的MongoDB 6.0副本集集群中，脚本无法完成，会随机在不同管道阶段报错Cannot $merge to internal database: admin

聚合管道仅在末尾包含如下$merge阶段：

{
  $merge: {
    into: "AGGREGATE_COLLECTION",
    on: "_id",
    whenMatched: "replace",
    whenNotMatched: "insert",
  },
}

聚合执行的核心代码：

var newdb= db.getSiblingDB(dynamicDatabase);
newdb.COLLECTION.aggregate([
  // 多阶段聚合管道
])

异常现象：仅在Unix shell手动执行脚本时会报错，使用同一Unix用户通过crontab调度执行则能成功完成，怀疑是集群配置问题，需排查方向。

• 对比手动执行与crontab的环境差异
  检查两种执行方式下的环境变量（如MONGO_DB_URI、PATH、MongoDB配置文件路径），尤其是MongoDB客户端的连接参数差异。crontab环境通常更精简，手动执行时可能继承了某些导致连接到admin库的环境变量或配置。
• 验证dynamicDatabase变量的取值
  在脚本开头添加print(dynamicDatabase)输出目标库名称，确认手动执行时是否存在变量被意外设为admin的情况。排查变量赋值逻辑，是否依赖环境变量或交互式输入，导致手动执行时取值异常。
• 检查MongoDB 6.0的权限与集群配置
  • 确认执行脚本的MongoDB用户权限，排查是否因权限配置异常，导致阶段执行时路由错误指向admin库。
  • 查看副本集的读写偏好、分片路由（若为分片集群）设置，确认手动执行时是否触发了不同的节点路由，导致某个节点误将合并操作指向admin库。
  • 对比MongoDB 6.0与7.0的$merge语法差异，确认是否存在版本间行为差异，比如into字段对数据库上下文的处理逻辑不同。
• 排查脚本的连接上下文
  在脚本开头添加print(db.getName())，确认手动执行时初始连接的数据库是否为admin。若执行mongo命令时未指定目标库，db默认指向admin，需排查getSiblingDB在边界场景（如dynamicDatabase为空）下的行为。
• 查看MongoDB集群日志
  手动执行脚本时，查看副本集主节点的日志，定位报错时的请求细节，比如合并操作的目标库是否被指定为admin，以及请求的发起来源、用户权限信息，区分是客户端问题还是集群配置问题。
• 检查运维工具的集群限制
  运维工具管理的集群可能添加了额外安全限制（如禁止直接操作admin库的特定命令、对聚合操作路由做特殊处理），手动执行的客户端请求可能触发了这些限制，而crontab执行的请求因参数或上下文不同绕过了限制。

内容的提问来源于stack exchange，提问作者Giacomo Giovannini