必须在admin数据库中创建拥有root角色的用户才能获得全局管理权限，其他方式均缺失关键功能；执行use admin后运行db.createUser({user:"dba01",pwd:"StrongPassw0rd!",roles:[{role:"root",db:"admin"}]})。
直接给 DBA 分配全局管理权限，就是创建一个在 admin 数据库中拥有 root 角色的用户 —— 这是唯一合法、有效且被官方支持的方式。其他任何绕过 admin 库、或用 readWriteAnyDatabase + userAdminAnyDatabase 等组合“模拟 root”的做法，都会缺失关键权限（比如无法执行 shutdownServer()、无法访问 config 和 local 库的某些集合、无法管理密钥文件等），实际运维中会卡住。
必须在 admin 数据库下创建用户才能获得 root 权限
MongoDB 的 root 角色只在 admin 数据库中定义且生效。哪怕你用 db.createUser() 在 test 库里写 { role: "root", db: "admin" }，MongoDB 会直接报错："role 'root' not found"。因为角色绑定的数据库上下文必须匹配声明位置。
- 先执行
use admin，再运行用户创建命令 - 用户凭证（用户名/密码）本身可以任意命名，但
db字段必须是"admin" - 即使该用户后续要操作
orders或logs库，也必须从admin库认证登录，再use orders切换 —— 权限不会丢失
创建 root 用户的最小可行命令
连接到 MongoDB 后（确保已启用认证，即启动时带 --auth 或配置了 security.authorization: enabled），执行：
use admin
db.createUser({
user: "dba01",
pwd: "StrongPassw0rd!",
roles: [ { role: "root", db: "admin" } ]
})
注意点：
-
pwd不支持空格或特殊字符过多的密码（如@、/、:可能触发 shell 解析问题，建议用单引号包裹整个命令或改用db.changeUserPassword()后续调整） - 不要加
mechanisms: ["SCRAM-SHA-256"]—— 新版默认就是它；显式指定反而可能因服务端不支持而失败 - 创建后立即退出并重新用
mongo -u dba01 -p --authenticationDatabase admin登录验证，避免误以为成功实则未生效
常见错误：用 readWriteAnyDatabase 替代 root 的后果
有人试图用 readWriteAnyDatabase + dbAdminAnyDatabase + userAdminAnyDatabase 组合来“凑齐 root”，这是危险的妥协：
- 无法执行
db.shutdownServer()—— 运维重启必须切回真正root用户 - 无法读取
config.system.sessions或local.oplog.rs的完整内容（部分字段被隐藏） - 无法在分片集群中调用
sh.removeShard()等关键命令 - 备份工具（如
mongodump --uri）可能因缺少backup角色而拒绝连接，即使有readWriteAnyDatabase
这些限制不是 bug，而是 MongoDB 显式设计的权限隔离 —— root 是唯一跨越所有边界的角色。
生产环境额外提醒
授予 root 意味着该账号可删除任意数据库、停机、修改复制集配置。所以：
- 绝不在开发/测试环境复用生产
root密码 - 使用
db.grantRolesToUser()增量授权比重建用户更安全（例如后期追加clusterMonitor） - 如果用 Kubernetes 或云服务（如阿里云 MongoDB），
root用户可能被平台拦截或重定向 —— 务必确认控制台是否允许自定义admin用户，或是否强制使用平台托管账号
真正麻烦的从来不是怎么加权限，而是加完之后忘了哪些操作必须用这个账号、哪些操作其实不该用它 —— 尤其是 config 和 local 库的隐式访问规则，很容易在自动化脚本里漏掉 --authenticationDatabase admin 参数导致静默失败。
