升级MongoDB 7.0后用户权限丢失，因mongodump默认跳过admin、config、local系统库；必须显式导出admin.system.users、system.roles和system.version并按序恢复，否则认证失败。
升级到 MongoDB 7.0 后，mongodump 和 mongorestore 默认不迁移用户、角色和权限数据——这不是 bug，是设计行为。必须显式启用，否则目标库只有空的 admin 数据库，所有账号都丢了。
为什么 upgrade 后用户权限没了？
MongoDB 的用户/角色元数据存在 admin.system.users、admin.system.roles 等集合里，但 mongodump 默认只导出「应用数据库」，跳过 admin、config、local 这三个系统库。5.0 升 7.0 本身不自动复制权限，升级后如果只 dump/restore 业务库，权限就彻底丢失。
-
mongodump --db myapp不会碰admin库 - 即使加了
--includeCollection，也不能跨库指定系统集合 - 7.0 的
authSchemaVersion是 7，但 5.0 用户数据仍可用，无需转换
正确导出用户权限的命令写法
必须单独 dump admin 数据库，并确保包含全部权限相关集合：
mongodump \ --host old-50-host:27017 \ --authenticationDatabase admin \ --username admin \ --password "xxx" \ --db admin \ --collection system.users \ --collection system.roles \ --collection system.version \ --out /backup/admin-dump
-
system.version必须一起导出，它记录authSchemaVersion，7.0 启动时会校验这个值 - 不要漏掉
system.roles—— 自定义角色依赖它，否则mongorestore会报 “role not found” - 如果用了 LDAP 或 x.509 认证，还需额外导出
system.authz（但 5.0→7.0 场景极少）
恢复时的权限与顺序陷阱
mongorestore 对 admin 库有严格顺序要求：必须先 restore system.version，再 system.roles，最后 system.users。任意颠倒会导致启动失败或认证拒绝。
- 错误做法：
mongorestore --db admin /backup/admin-dump/admin（批量还原，顺序不可控） - 正确做法：分三次调用，按集合名排序执行：
mongorestore --db admin --collection system.version /backup/admin-dump/admin/system.version.bson - restore 前确认目标 7.0 实例已启用
security.authorization: enabled，否则会忽略权限数据 - restore 完成后，用
mongo --eval "db.getUsers()"验证，别只看命令返回 success
升级后直接用 mongosync 迁移？不行
mongosync（替代已 EOL 的 mongomirror）从 7.0.13+ 开始支持实时同步，但它完全不传输用户/角色，只同步业务数据。官方文档明确写着：“User and role definitions are not synchronized.”
- 哪怕源是 5.0 副本集、目标是 7.0 Atlas 集群，
mongosync也跳过admin库 - 想靠它“顺带”迁移权限，只会得到一个没账号、连不上 shell 的空集群
- 唯一办法仍是手动 dump/restore
admin库，或用 Ops Manager 的 backup/restore 流程（它内部封装了正确顺序）
最容易被忽略的是 system.version 的 restore 时机——它必须在任何用户或角色之前写入，且不能被 mongorestore 的并发逻辑打乱顺序。手误一次，整个认证体系就瘫痪，比数据不同步更难排查。
