MongoDBclusterAdmin与clusterManager如何选择？

clusterAdmin 包含 dropDatabase 等高危操作，可无确认删除任意数据库（如 config、local），导致同步中断或级联故障；而 clusterManager 仅提供安全的集群管理能力，需搭配 clusterMonitor、backup 等角色才能支撑 mongosync 正常运行。

直接结论：除非你明确需要 dropDatabase 权限，否则用 clusterManager 更安全；clusterAdmin 是全量集群控制权，不该轻易授予。

clusterAdmin 包含哪些实际危险操作？

它不只是“比 clusterManager 多一点权限”，而是叠加了 dropDatabase 动作 —— 这意味着该用户能直接删掉任意数据库（包括 config、local），且无需二次确认。在自动化脚本或配置错误时，极易引发级联故障。

1. 执行 db.getSiblingDB("admin").runCommand({ dropDatabase: 1 }) 会成功，即使目标库正在被同步或备份
2. 误配 mongosync 的目标集群用户为 clusterAdmin，可能导致反向同步时清空源库（尤其在多重反转场景）
3. Cloud Manager / Ops Manager 导入流程若复用该账号，可能意外触发清理逻辑

clusterManager 足够支撑哪些关键运维动作？

它覆盖绝大多数集群管理需求，且不带破坏性动作，是生产环境推荐的“最小必要权限”起点。

1. 可执行 replSetGetConfig、replSetGetStatus、listShards、getShardMap —— mongosync 启动和状态检查必需
2. 能调用 setClusterParameter 和 getClusterParameter（需配合 clusterMonitor 查看当前值）
3. 支持 backup 和 restore 操作（但需额外显式授予这两个角色）
4. 对分片集群的 moveChunk、splitChunk 等管理命令也足够

权限组合比单角色更重要

真实场景中几乎不会只靠一个角色干活。clusterManager 必须搭配 clusterMonitor 才能读取集群状态，搭配 backup 才能执行备份 —— 单独授 clusterManager 会导致 mongosync 报错 "not authorized on admin to execute command { getClusterParameter: "*" }"。

1. 典型自托管同步用户权限： clusterManager + clusterMonitor + backup + restore + readWriteAnyDatabase
2. 如果要用 mongosync --reverse，目标集群还需加 dbAdminAnyDatabase（不是 clusterAdmin）
3. Atlas 环境下直接用 atlasAdmin，它已内建等效能力，无需手动拼凑

最容易被忽略的一点：权限变更后，mongosync 进程必须重启才能生效 —— 它不会动态刷新认证上下文。哪怕你刚 grantRolesToUser 完，旧连接仍按旧权限跑，直到下次启动。