运维人员应选用clustermonitor+hostmanager+backup组合角色，因其覆盖监控、主机管理、备份核心任务且无高危变更权限，避免使用clusteradmin或dbadminanydatabase等危险角色。
运维人员该用哪个内置角色？
直接给 clusterAdmin 是最常见但最危险的做法。这个角色在 admin 数据库中授予后，拥有 dropDatabase()、修改复制集配置、重启节点等高危权限，一旦账号泄露或误操作，整个集群可能瘫痪。
真正适合日常运维的组合是：clusterMonitor + hostManager + backup（如需备份）——它们分别覆盖监控、主机管理、备份三类核心任务，且无写入或变更集群拓扑的能力。
-
clusterMonitor：只读访问serverStatus、top、currentOp等关键指标，但不能调用killOp -
hostManager：可查看和调整日志级别、刷新配置（setParameter）、管理内存映射文件，但不能重启进程或修改网络绑定 - 若需执行
mongodump，必须显式授予backup角色，且仅在admin数据库中有效
为什么不能把 dbAdminAnyDatabase 当作运维角色？
dbAdminAnyDatabase 允许对所有数据库执行索引创建/删除、统计收集、collMod 等操作，但它不包含任何集群级权限——这意味着运维人员无法查看复制集状态、无法切换主从、无法诊断慢查询根源（因为 system.profile 读取依赖 clusterMonitor）。更麻烦的是，它允许在任意数据库上重建索引，而重建大集合索引会阻塞写入，极易引发业务抖动。
实际运维中，你更常需要的是：跨库查看 db.currentOp()、强制终止长事务、动态调整 slowms 阈值——这些都超出 dbAdminAnyDatabase 范围，必须靠 clusterMonitor 或自定义角色补足。
如何用自定义角色限制 killOp 权限？
运维有时必须终止异常连接，但直接开放 killOp 太危险。MongoDB 不支持按条件过滤 killOp，所以只能通过角色隔离：创建一个专用角色，仅允许对当前操作（currentOp）执行 killOp，且禁止其他写操作。
示例命令（在 admin 数据库执行）：
db.createRole({
role: "limitedKillOp",
privileges: [{
resource: { cluster: true },
actions: ["killOp", "currentOp"]
}],
roles: []
})
注意两点：
- 必须指定
resource: { cluster: true }，否则killOp无效 - 这个角色不能和
readWriteAnyDatabase混用，否则等于开放全库写权限 - 授予该角色时，务必搭配
clusterMonitor，否则用户连哪些 op 可杀都看不到
验证库选错会导致什么？
运维账号必须在 admin 数据库中创建，且 db 字段必须设为 "admin"。如果误设为 "myapp"，会出现两个致命问题：
- 登录时必须显式指定
--authenticationDatabase myapp，否则认证失败（即使密码正确） - 该账号将无法继承
admin数据库中的角色（如clusterAdmin），因为角色查找只在验证库和admin中进行，而它自己的验证库里没存这些角色定义
简单说：验证库不是“管哪个库”，而是“到哪儿找你的角色”。运维角色全在 admin.system.roles 里，所以验证库必须是 admin。
