【安全与故障排查】06-【复盘】生产数据库删库事故：RTO4小时恢复纪实

【复盘】生产数据库删库事故：RTO 4小时恢复纪实

专栏： 安全 & 故障排查

难度： 专家

标签： 事故复盘 数据库恢复 RTO 灾备 MySQL

前言

2024年某周五下午4点，一条误操作的 DROP DATABASE 让我们的生产数据库消失了。这是那4小时的完整记录，希望所有DBA和运维工程师都读一遍。

事故起因

一名新员工在执行数据库迁移脚本时，将测试环境的数据库名写错，在生产数据库上执行了 DROP DATABASE prod_db。

sql 复制代码

-- 原本应该在测试库执行
DROP DATABASE test_db;

-- 实际在生产库执行了
DROP DATABASE prod_db;   -- 包含5000万条数据

时间线

时间	操作
16:03	误操作执行，数据库消失
16:05	应用报错告警触发，业务中断
16:08	值班工程师登录确认数据库丢失
16:15	启动紧急响应，通知DBA、架构师、业务负责人
16:30	确认备份文件可用，制定恢复方案
17:00	开始从全量备份恢复
18:30	全量恢复完成，开始应用binlog增量
19:45	数据恢复到16:03，业务验证数据完整
20:10	业务全面恢复

实际RTO: 4小时7分钟

恢复过程详解

第一步：停止写入，保存现场

bash 复制代码

# 立刻停止业务写入（防止binlog被覆盖）
systemctl stop application

# 备份当前binlog
cp /var/lib/mysql/mysql-bin.* /data/recovery/

# 查看最后的binlog文件和位置
mysql -e "SHOW MASTER STATUS\G"

第二步：从备份恢复全量数据

bash 复制代码

# 查找最近的全量备份
ls -lt /backup/mysql/ | head -5
# 确认使用：2024-xx-xx_00:00_full.sql.gz

# 恢复全量备份（约需要1.5小时）
gunzip -c /backup/mysql/full.sql.gz | mysql -u root -p

# 检查数据量
mysql -e "SELECT COUNT(*) FROM prod_db.orders;"
# 5000万 - N条（N为事故到上次备份之间的新增数据）

第三步：应用 binlog 追回增量数据

bash 复制代码

# 从全量备份的binlog位置到事故发生时间点应用增量
mysqlbinlog \
  --start-position=12345678 \
  --stop-datetime="2024-XX-XX 16:02:59" \
  /data/recovery/mysql-bin.000021 \
  /data/recovery/mysql-bin.000022 | \
  mysql -u root -p

# 验证数据量（应该恢复到接近事故前）
mysql -e "SELECT COUNT(*) FROM prod_db.orders;"

事故根因分析

权限过大 ：新员工拥有生产数据库的 DROP 权限
无二次确认：执行危险 DDL 没有任何确认机制
测试生产环境混淆：脚本硬编码数据库名，无环境变量保护

改进措施

sql 复制代码

-- 1. 最小权限原则：新员工只给只读权限
REVOKE ALL ON *.* FROM 'newuser'@'%';
GRANT SELECT ON prod_db.* TO 'newuser'@'%';

-- 2. 添加SQL审计（使用Percona audit plugin）
INSTALL PLUGIN audit_log SONAME 'audit_log.so';

-- 3. 关键操作需要DBA二次确认
-- 流程：提交工单 → DBA review → 双人执行

bash 复制代码

# 4. 改善备份策略
# 之前：全量备份每天1次，binlog 7天
# 改后：全量备份每天2次，binlog 30天，每小时上传OSS
# 目标RPO < 30分钟

# 5. 生产数据库配置 super_read_only
mysql -e "SET GLOBAL super_read_only=ON;"
# 所有写操作需要先关闭此选项（提供操作窗口）

结语： 这次事故最贵的教训：备份是一切恢复的基础。没有可用的备份，任何技术都救不了你。每季度测试一次备份可恢复性，是运维的最低标准。