MongoDB: 备份恢复、安全与运维
最后更新:2026-08-26
运维是 MongoDB 生产部署的关键——掌握备份、安全、监控能避免 90% 的生产事故。
1. 你将学到
- mongodump / mongorestore 逻辑备份
- Ops Manager / Atlas 备份策略
- SCRAM 认证与 RBAC
- TLS/SSL 加密
- 运维监控(serverStatus / dbStats / 慢查询)
graph TB
subgraph "备份策略"
A1[每日全量备份<br/>mongodump] --> S3[(S3/OSS<br/>对象存储)]
A2[oplog 持续<br/>增量] --> S3
A3[Atlas PITR<br/>时间点恢复] --> S3
end
subgraph "恢复场景"
R1[误删数据] --> R2[mongorestore]
R3[整库丢失] --> R2
R4[指定时间点] --> R5[oplogReplay]
R2 --> R6[✅ 数据恢复]
R5 --> R6
end
style R6 fill:#d4edda
2. mongodump 逻辑备份
概念说明:mongodump 是 MongoDB 官方的逻辑备份工具——它读取集合数据并导出为 BSON/JSON 文件。逻辑备份是"导出数据"而非"复制文件",因此可以跨版本、跨平台恢复,但备份大数据库速度较慢。
工作原理:mongodump 连接到 MongoDB,逐集合逐文档读取并序列化为 BSON 格式写入磁盘。支持 gzip 压缩、条件过滤、oplog 包含(用于 PITR)。备份期间不锁集合(热备份),但大集合备份可能影响性能。
逻辑备份 vs 物理备份:
| 维度 | 逻辑备份 (mongodump) | 物理备份 (文件拷贝) |
|---|---|---|
| 实现 | 读取数据 → 序列化 → 写文件 | 直接复制数据文件 |
| 速度 | 慢(需读取+序列化) | 快(文件级拷贝) |
| 跨版本 | ✅ 支持 | ❌ 绑定引擎版本 |
| 选择性 | ✅ 按库/集合/条件 | ❌ 全量 |
| 空间 | 较小(可压缩) | 较大(原始文件) |
| 一致性 | 单集合一致 | 需锁或副本集快照 |
| 恢复粒度 | 灵活(库/集合/文档) | 全库 |
RPO/RTO 概念:
| 概念 | 含义 | 例子 |
|---|---|---|
| RPO (Recovery Point Objective) | 可接受的最大数据丢失量 | RPO=1h = 最多丢失 1 小时数据 |
| RTO (Recovery Time Objective) | 可接受的最大恢复时间 | RTO=4h = 4 小时内恢复服务 |
# === 备份整个数据库 ===
mongodump --uri="mongodb://localhost:27017/shopdb" --out=/backup/2026-07-01
# === 备份指定集合 ===
mongodump --uri="mongodb://localhost:27017/shopdb" --collection=users --out=/backup/users
# === 压缩备份 ===
mongodump --uri="mongodb://localhost:27017" --gzip --archive=/backup/shopdb.gz
# === 仅备份元数据 ===
mongodump --uri="mongodb://localhost:27017" --db=shopdb --collection=users --query='{"role":"admin"}'
mongodump 关键参数:
| 参数 | 说明 | 示例 |
|---|---|---|
--uri |
连接字符串 | mongodb://user:pass@host:port/db |
--out |
输出目录 | /backup/2026-07-01 |
--gzip |
gzip 压缩 | 减小 60-80% 体积 |
--archive |
单文件归档 | --archive=backup.gz |
--oplog |
包含 oplog(PITR 必须) | --oplog |
--collection |
指定集合 | --collection=users |
--query |
条件过滤 | --query='{"role":"admin"}' |
3. mongorestore 恢复
概念说明:mongorestore 是 mongodump 的配对恢复工具——将 BSON/JSON 备份文件导入 MongoDB。支持全量恢复、选择性恢复、PITR(时间点恢复)等模式。
工作原理:mongorestore 读取备份目录或归档文件,逐集合插入文档。--drop 选项先删除现有集合再恢复(覆盖模式)。配合 --oplogReplay 可重放 oplog 实现时间点恢复。
恢复模式对比:
| 模式 | 命令选项 | 适用场景 |
|---|---|---|
| 全量恢复 | mongorestore /backup/db |
整库恢复到备份时刻 |
| 覆盖恢复 | --drop |
清空后恢复(测试环境) |
| 选择性恢复 | --nsInclude |
仅恢复特定集合 |
| PITR 恢复 | --oplogReplay |
恢复到指定时间点 |
| 压缩归档恢复 | --gzip --archive=file.gz |
从压缩归档恢复 |
# === 恢复整个备份 ===
mongorestore --uri="mongodb://localhost:27017" /backup/2026-07-01
# === 恢复指定数据库 ===
mongorestore --uri="mongodb://localhost:27017" /backup/2026-07-01/shopdb
# === 恢复 gzip 压缩备份 ===
mongorestore --uri="mongodb://localhost:27017" --gzip --archive=/backup/shopdb.gz
# === 恢复并覆盖现有数据 ===
mongorestore --uri="mongodb://localhost:27017" --drop /backup/2026-07-01
要点解析:
--drop会先删除集合再恢复,生产环境慎用(可能丢失备份后的新数据)- mongorestore 插入数据会触发索引构建,大集合恢复较慢
- 恢复到现有数据库时,
_id冲突会导致重复文档跳过,用--drop避免冲突
4. 备份策略
概念说明:备份策略是运维的核心——它决定了 RPO(最大数据丢失量)和 RTO(最大恢复时间)。不同业务场景需要不同的备份频率、保留策略和恢复方案。
备份策略对比:
| 策略 | 频率 | 保留 | RPO | RTO | 适用 | 成本 |
|---|---|---|---|---|---|---|
| 每日全量 | 每天凌晨 | 7-30 天 | 24h | 数小时 | 小型数据库 | 低 |
| 每小时增量 | 每小时 | 24-48 小时 | 1h | 数小时 | 中型数据库 | 中 |
| oplog 持续 | 实时 | 7 天 | < 1s | 分钟级 | 大型数据库 | 高 |
| Atlas PITR | 自动 | 35 天 | 秒级 | 分钟级 | Atlas 云服务 | 按用量 |
| 文件快照 | 按需 | 7-30 天 | 快照时间 | 分钟级 | LVM/EBS 支持 | 低 |
备份策略选择流程:
graph TB
A{业务类型?} -->|非关键<br/>日志/缓存| B[每日全量<br/>RPO=24h]
A -->|一般业务<br/>用户/订单| C{数据量?}
A -->|关键业务<br/>金融/支付| D[oplog持续<br/>RPO<1s]
C -->|< 100GB| E[每日全量+<br/>oplog PITR]
C -->|> 100GB| F[文件快照+<br/>oplog持续]
style D fill:#d4edda
style B fill:#fff3cd
PITR(Point-In-Time Recovery)原理:先恢复全量备份,再重放备份时刻到目标时间点之间的 oplog,实现精确到秒的时间点恢复。
sequenceDiagram
participant Full as 全量备份
participant Oplog as oplog增量
participant Target as 目标时间点
Note over Full: 备份时刻 T0
Full->>Oplog: 恢复T0全量数据
Note over Oplog: T0 → T1 之间的oplog
loop 重放oplog
Oplog->>Target: 逐条重放写操作
end
Note over Target: 恢复到精确时间点 T1
| 策略 | 频率 | 保留 | 适用 |
|---|---|---|---|
| 每日全量 | 每天凌晨 | 7-30 天 | 小型数据库 |
| 每小时增量 | 每小时 | 24-48 小时 | 中型数据库 |
| oplog 持续 | 实时 | 7 天 | 大型数据库(基于副本集 oplog) |
| Atlas PITR | 自动 | 35 天 | Atlas 云服务 |
▶ 示例 1: PITR 时间点恢复实战
# ShopHub 误删了 2026-07-01 10:00-10:30 的订单数据,需要恢复到 10:00 的状态
# 1. 恢复前一天的全量备份
mongorestore --uri="mongodb://localhost:27017/shopdb_recovery" --drop /backup/2026-06-30/shopdb
# 2. 重放 oplog 到目标时间点
mongorestore --uri="mongodb://localhost:27017/shopdb_recovery" --oplogReplay --oplogLimit=1750604400 /backup/2026-06-30/oplog.bson
# 3. 验证恢复数据
mongosh --port 27017 shopdb_recovery --eval 'db.orders.count()'
# 4. 将恢复的数据导出并导入到生产
mongodump --uri="mongodb://localhost:27017/shopdb_recovery" --collection=orders --query='{"createdAt":{"$gte":{"$date":"2026-07-01T10:00:00Z"},"$lt":{"$date":"2026-07-01T10:30:00Z"}}}' --out=/recovery/orders
mongorestore --uri="mongodb://localhost:27017/shopdb" /recovery/orders
输出:
test> // MongoDB shell 操作成功
5. 用户与认证
概念说明:安全是 MongoDB 生产部署的第一道防线。SCRAM(Salted Challenge Response Authentication Mechanism)是 MongoDB 默认的认证机制,RBAC(Role-Based Access Control)基于角色控制权限。最小权限原则是安全的核心——每个用户仅授予完成任务所需的最小权限。
SCRAM 认证原理:客户端发送用户名,服务器返回随机 salt 和迭代次数,客户端用密码 + salt 做多次哈希运算生成证明,服务器验证证明是否匹配存储的哈希。密码从不在网络上明文传输。
sequenceDiagram
participant C as 客户端
participant S as MongoDB服务器
C->>S: 1. 用户名
S-->>C: 2. salt + iterationCount + storedKey
C->>C: 3. password + salt → PBKDF2 → clientKey → storedKey
C->>S: 4. clientProof(数字签名)
S->>S: 5. 验证 clientProof
S-->>C: 6. 认证成功 ✅ / 失败 ❌
Note over C,S: 密码从不在网络传输
RBAC 权限模型:
| 层级 | 说明 |
|---|---|
| 用户(User) | 认证身份,拥有一个或多个角色 |
| 角色(Role) | 权限集合,可继承其他角色 |
| 权限(Privilege) | 资源 + 操作的组合 |
| 资源(Resource) | 数据库/集合/集群级别 |
(1) SCRAM 认证
// === 创建管理员用户 ===
db.createUser({
user: 'admin',
pwd: 'SecurePass123!',
roles: [
{ role: 'userAdminAnyDatabase', db: 'admin' },
{ role: 'readWriteAnyDatabase', db: 'admin' }
]
});
// === 创建应用用户 ===
db.createUser({
user: 'app_user',
pwd: 'AppPass456!',
roles: [{ role: 'readWrite', db: 'shopdb' }]
});
// === 启用认证(mongod 启动参数)===
mongod --auth --bind_ip_all
(2) RBAC 角色
| 内置角色 | 权限 | 适用用户 |
|---|---|---|
read |
读所有集合 | 分析师 |
readWrite |
读写所有集合 | 应用 |
dbAdmin |
数据库管理 | DBA |
userAdmin |
用户管理 | DBA |
dbOwner |
上述所有权限 | 负责人 |
readAnyDatabase |
读所有数据库 | 跨库分析师 |
readWriteAnyDatabase |
读写所有数据库 | 跨库应用 |
userAdminAnyDatabase |
管理所有数据库用户 | 超级DBA |
dbAdminAnyDatabase |
管理所有数据库 | 超级DBA |
backup |
备份权限 | 备份脚本 |
restore |
恢复权限 | 恢复脚本 |
root |
超级用户 | 紧急维护 |
最小权限原则:
| 用户 | 推荐角色 | 说明 |
|---|---|---|
| 应用用户 | readWrite (单库) |
仅读写业务数据库 |
| 备份用户 | backup + readAnyDatabase |
备份所需最小权限 |
| 分析用户 | read (单库) |
仅读权限 |
| DBA | userAdmin + dbAdmin |
管理权限,非超管 |
// === 自定义角色 ===
db.createRole({
role: 'orderManager',
privileges: [
{ resource: { db: 'shopdb', collection: 'orders' }, actions: ['find', 'insert', 'update'] },
{ resource: { db: 'shopdb', collection: 'products' }, actions: ['find'] }
],
roles: []
});
// === 授权 ===
db.grantRolesToUser('app_user', [{ role: 'orderManager', db: 'shopdb' }]);
▶ 示例 2: 最小权限 RBAC 配置
// TechCorp:为不同团队配置最小权限
// 1. 应用服务账号(仅读写 shopdb)
db.createUser({
user: 'app_service',
pwd: 'AppSecurePass!',
roles: [{ role: 'readWrite', db: 'shopdb' }]
});
// 2. 备份服务账号(仅备份权限)
db.createUser({
user: 'backup_service',
pwd: 'BackupSecurePass!',
roles: [
{ role: 'backup', db: 'admin' },
{ role: 'readAnyDatabase', db: 'admin' }
]
});
// 3. 数据分析团队(只读 + 特定集合)
db.createRole({
role: 'analyticsReader',
privileges: [
{ resource: { db: 'shopdb', collection: 'orders' }, actions: ['find'] },
{ resource: { db: 'shopdb', collection: 'products' }, actions: ['find'] }
],
roles: []
});
db.createUser({
user: 'analyst',
pwd: 'AnalystPass!',
roles: [{ role: 'analyticsReader', db: 'shopdb' }]
});
// 4. 验证权限
db.auth('analyst', 'AnalystPass!');
db.orders.find({}); // ✅ 可以读
db.orders.insertOne({}); // ❌ 权限不足
输出:
// mongoose 操作成功执行
// 数据库查询/更新结果
6. TLS/SSL 加密
概念说明:TLS/SSL 加密保护 MongoDB 网络通信——防止中间人攻击、数据窃听和篡改。生产环境必须启用 TLS,尤其是跨机房/跨云通信时。
工作原理:TLS 通过证书验证服务器身份,建立加密通道。MongoDB 支持 x.509 证书认证(可替代 SCRAM),双向 TLS(mTLS)可同时验证客户端和服务器身份。
加密层级:
| 层级 | 加密方式 | 保护范围 |
|---|---|---|
| 传输层 | TLS/SSL | 网络通信(客户端↔服务器、节点间) |
| 存储层 | WiredTiger 加密 | 数据文件(静态加密) |
| 字段层 | 应用层加密 | 敏感字段(如密码、身份证) |
# === 启动带 SSL 的 mongod ===
mongod --tlsMode requireTLS --tlsCertificateKeyFile /etc/ssl/mongodb.pem
# === 客户端连接 ===
mongosh "mongodb://localhost:27017/shopdb?ssl=true&sslCertificateKeyFile=/etc/ssl/client.pem"
TLS 配置参数:
| 参数 | 说明 | 推荐值 |
|---|---|---|
--tlsMode |
TLS 模式 | requireTLS(生产) |
--tlsCertificateKeyFile |
服务器证书+私钥 | PEM 格式 |
--tlsCAFile |
CA 证书 | 用于验证客户端证书 |
--tlsAllowInvalidCertificates |
允许无效证书 | ❌ 生产禁用 |
要点解析:
- 自建集群可用自签名证书,Atlas 默认启用 TLS
- mTLS(双向 TLS)可实现证书认证,替代密码认证
- TLS 会增加约 5-10% 的连接延迟,但对数据安全至关重要
7. 运维监控
概念说明:运维监控是 MongoDB 生产部署的"健康仪表盘"——通过 serverStatus、dbStats、慢查询分析等工具,实时掌握数据库健康状态,及时发现和预防问题。
监控体系:
| 监控层级 | 工具 | 关注指标 |
|---|---|---|
| 实例级 | serverStatus() |
连接数、操作计数、内存 |
| 数据库级 | db.stats() |
数据量、索引量、集合数 |
| 集合级 | collStats() |
文档数、大小、索引效率 |
| 查询级 | Profiler / explain | 慢查询、执行计划 |
| 索引级 | $indexStats |
索引使用率 |
(1) serverStatus
核心指标:
| 指标 | 说明 | 健康范围 | 告警阈值 |
|---|---|---|---|
connections.current |
当前连接数 | < 1000 | > 8000 |
connections.available |
可用连接数 | > 50000 | < 1000 |
opcounters.query |
查询操作数/秒 | 基准 | 突增 10 倍 |
opcounters.insert |
插入操作数/秒 | 基准 | 突增 10 倍 |
mem.resident |
常驻内存(MB) | < 总内存 80% | > 总内存 95% |
uptime |
运行时间(秒) | > 86400 | < 3600(频繁重启) |
db.serverStatus();
// {
// host: 'mongo1',
// version: '7.0.5',
// process: 'mongod',
// uptime: 864000,
// connections: { current: 150, available: 83860 },
// opcounters: {
// insert: 1234567,
// query: 9876543,
// update: 234567,
// delete: 12345
// },
// mem: { resident: 1024, virtual: 4096 },
// ...
// }
(2) 数据库统计
db.stats();
// {
// db: 'shopdb',
// collections: 10,
// objects: 1000000,
// dataSize: 524288000,
// storageSize: 268435456,
// indexes: 20,
// indexSize: 52428800
// }
(3) 慢查询分析
概念说明:慢查询是 MongoDB 性能问题的首要信号。通过 Profiler 记录超过阈值的查询操作,分析执行计划和索引使用情况,是性能优化的标准流程。
| Profiling Level | 说明 | 性能影响 |
|---|---|---|
| 0 | 关闭 | 无 |
| 1 | 仅慢查询 | 极低 |
| 2 | 记录所有操作 | 中(仅调试用) |
// === 启用慢查询日志(>100ms)===
db.setProfilingLevel(2, { slowms: 100 });
// === 查看慢查询 ===
db.system.profile.find({ millis: { $gt: 100 } })
.sort({ ts: -1 })
.limit(10);
(4) 索引使用统计
db.products.aggregate([{ $indexStats: {} }]);
// 找出未使用的索引
监控告警配置建议:
| 告警项 | 阈值 | 通知方式 |
|---|---|---|
| 连接数 > 80% 最大值 | current > 64000 | 邮件 + 短信 |
| 慢查询 > 10/min | 持续 5 分钟 | Slack |
| 内存 > 90% | resident > 90% 总内存 | 邮件 |
| 磁盘 > 85% | storageSize > 85% 磁盘 | 邮件 + 短信 |
| 复制延迟 > 10s | optimeDate 偏差 | 邮件 |
8. 常见运维命令
概念说明:日常运维需要处理当前操作、长事务、索引维护、集合压缩等问题。MongoDB 提供了一套运维命令,帮助 DBA 快速诊断和处理生产问题。
运维命令速查:
| 场景 | 命令 | 说明 |
|---|---|---|
| 查看当前操作 | db.currentOp() |
找到长查询/死锁 |
| 杀死操作 | db.killOp(opId) |
终止问题操作 |
| 压缩集合 | db.runCommand({compact:'col'}) |
回收碎片空间 |
| 重建索引 | db.col.reIndex() |
修复索引碎片 |
| 查看连接 | db.serverStatus().connections |
连接数统计 |
| 切换日志 | db.adminCommand({logRotate:1}) |
日志轮转 |
| 强制同步 | rs.syncFrom('host:port') |
指定同步源 |
// === 当前操作 ===
db.currentOp({ "op": "query" });
// === 杀进程 ===
db.killOp(opId);
// === 压缩集合 ===
db.runCommand({ compact: 'products' });
// === 重建索引 ===
db.products.reIndex();
// === 查看连接 ===
db.serverStatus().connections;
运维操作注意事项:
| 操作 | 锁类型 | 阻塞风险 | 建议 |
|---|---|---|---|
compact |
排他锁 | 高 | 维护窗口执行 |
reIndex |
排他锁 | 高 | 维护窗口执行 |
killOp |
无锁 | 无 | 随时可执行 |
currentOp |
无锁 | 无 | 随时可执行 |
logRotate |
无锁 | 无 | 随时可执行 |
紧急故障处理流程:
db.currentOp()找到长操作db.killOp(opId)杀死问题操作db.serverStatus().connections检查连接数- 如果连接数爆满,考虑临时调低应用连接池大小
- 事后用 Profiler 分析根因,添加索引或优化查询
▶ 示例:完整备份策略 + RBAC 安全配置
# === 1. 每日自动备份脚本(backup-daily.sh)===
#!/bin/bash
set -e
DATE=$(date +%Y%m%d)
BACKUP_DIR=/backup/mongodb/$DATE
RETENTION_DAYS=7
# 1.1 全量备份(gzip 压缩)
mongodump --uri="mongodb://backup_user:SecurePass@mongo1:27017,mongo2:27017,mongo3:27017/shopdb?replicaSet=rs0" --gzip --archive=$BACKUP_DIR.gz --oplog # 包含 oplog,支持 PITR
# 1.2 上传到 S3
aws s3 cp $BACKUP_DIR.gz s3://my-bucket/mongodb-backups/$DATE/
# 1.3 清理 7 天前的本地备份
find /backup/mongodb/ -name "*.gz" -mtime +$RETENTION_DAYS -delete
# 1.4 记录备份日志
echo "[$(date)] Backup completed: $BACKUP_DIR.gz ($(du -h $BACKUP_DIR.gz | cut -f1))" >> /var/log/mongodb-backup.log
# 1.5 添加到 crontab(每天凌晨 2 点)
# 0 2 * * * /usr/local/bin/backup-daily.sh
# === 2. 恢复演练 ===
# 2.1 查看可用备份
ls -lh /backup/mongodb/
# 2.2 恢复到测试环境
mongorestore --uri="mongodb://localhost:27017/shopdb_test" --gzip --archive=/backup/mongodb/20260701.gz --drop # 覆盖现有数据
# 2.3 PITR 恢复到指定时间点
mongorestore --uri="mongodb://localhost:27017" --gzip --archive=/backup/mongodb/20260701.gz --oplogReplay --pointInTime=2026-07-01T10:30:00
输出:
test> // MongoDB shell 操作成功
// === 3. 启用认证 + 创建 RBAC 用户 ===
// 3.1 创建管理员用户(第一个必须)
db.createUser({
user: 'root',
pwd: 'RootSecurePass!',
roles: [{ role: 'root', db: 'admin' }]
});
// 3.2 创建备份专用用户(最小权限)
db.createUser({
user: 'backup_user',
pwd: 'BackupPass!',
roles: [
{ role: 'backup', db: 'admin' },
{ role: 'readAnyDatabase', db: 'admin' }
]
});
// 3.3 创建应用用户(读写 shopdb)
db.createUser({
user: 'app_user',
pwd: 'AppPass!',
roles: [{ role: 'readWrite', db: 'shopdb' }]
});
// 3.4 创建只读分析用户
db.createUser({
user: 'analytics_user',
pwd: 'AnalyticsPass!',
roles: [{ role: 'read', db: 'shopdb' }]
});
// 3.5 启用 TLS/SSL(mongod 启动参数)
// mongod --tlsMode requireTLS --tlsCertificateKeyFile /etc/ssl/mongodb.pem --auth
// === 4. 监控告警 ===
// 启用慢查询日志
db.setProfilingLevel(2, { slowms: 100 });
// 查看慢查询 Top 10
db.system.profile.find({ millis: { $gt: 100 } })
.sort({ ts: -1 })
.limit(10)
.forEach(p => print(`[${p.ts}] ${p.command.find}: ${p.millis}ms`));
// 监控连接数
const stats = db.serverStatus();
print(`Active connections: ${stats.connections.current}/${stats.connections.available}`);
// 告警阈值:current > 1000 → 邮件告警
// === 5. 自动化巡检脚本 ===
function dailyHealthCheck() {
print('=== MongoDB Daily Health Check ===');
// 5.1 副本集状态
const rsStatus = rs.status();
const primary = rsStatus.members.find(m => m.stateStr === 'PRIMARY');
print(`Primary: ${primary.name}`);
// 5.2 oplog 窗口(避免滚动覆盖)
const oplogWindow = primary.optimeDate ? (Date.now() - primary.optimeDate.getTime()) / 1000 : 0;
print(`Oplog window: ${Math.floor(oplogWindow / 3600)} hours`);
if (oplogWindow > 24 * 3600) print('⚠️ WARNING: oplog window > 24h');
// 5.3 索引使用率
const indexes = db.products.aggregate([{ $indexStats: {} }]).toArray();
const unused = indexes.filter(i => i.accesses.ops === 0);
print(`Unused indexes: ${unused.length}`);
if (unused.length > 0) {
unused.forEach(i => print(` - ${i.name}`));
}
}
dailyHealthCheck();
输出:每日自动备份 + 7 天保留;RBAC 三层用户隔离权限;监控告警及时发现性能问题。
❓ 常见问题
📖 小节
- mongodump/mongorestore 逻辑备份
- 备份策略:每日全量 + oplog 持续 + Atlas PITR
- SCRAM 认证 + RBAC 角色权限
- TLS/SSL 加密
- 监控:serverStatus / dbStats / 慢查询 / $indexStats
- 运维命令:currentOp / killOp / compact / reIndex
📝 作业
- 基础题(⭐):用 mongodump 备份 shopdb 数据库,用 mongorestore 恢复。
- 基础题(⭐):创建 admin 用户和 app_user,并授权。
- 进阶题(⭐⭐):实现每日备份脚本(cron + mongodump + 压缩 + 清理 7 天前)。
- 进阶题(⭐⭐):启用慢查询分析,找出 Top 10 慢查询。
- 挑战题(⭐⭐⭐):完整运维方案(备份脚本 + 用户权限 + TLS + 监控告警)。