404E Blog
更新于 2026/02/27

同事误删mysql库补救办法

未分类

发现问题

今天下午同事突然跑来找我说不小心把库删了，问我会不会恢复，我从来没有这种删库恢复的经验，自然是要学习一下的，直接开始帮他恢复

查找解决办法

被删库的机器，这儿就叫他243，243的应用和数据库在同一个服务器上

  1. 首先先停止了应用防止继续写入或者丢失服务数据
  2. 检查mysql的binlog是否开启 SHOW VARIABLES LIKE 'log_bin%';，发现是开着的
  3. 检查binlog是否完整 ls /opt/mysql/data/ 发现缺少了几乎一半的binlog，推测是开启了过期清理
  4. 这个时候了解服务器运维的同事提出可以问机房的人恢复硬盘备份，并联系了相关同事
  5. 等待了一段时间，运维同事恢复了前一天的一个备份到一台新机器上，这儿叫他229

解决过程

在等待的时间里，确定了解决方案

  1. 检查两个服务器的binlog id差异
  2. 在243上找到最新的删库的binlog id
  3. 在229上找到最新的binlog id
  4. 在243生成两个binlog id中间差异的sql文件
  5. 将sql文件scp到229服务器上
  6. 229服务器的mysql执行sql补全缺失的数据

其中第二步可以在等待的时候完成

检查binlog的脚本 - 243

mysqlbinlog --no-defaults -v --base64-output=DECODE-ROWS  --stop-position=287225397  binlog.000075 | tail -n 500 > ~/tail.log

# at 287225397
#260227 15:46:29 server id 1  end_log_pos 287225556 CRC32 0x97e6fb47 	Query	thread_id=663510	exec_time=1	error_code=0	Xid = 583720608
use `laboratory`/*!*/;
SET TIMESTAMP=1772178389/*!*/;
SET @@session.pseudo_thread_id=663510/*!*/;
SET @@session.foreign_key_checks=0/*!*/;
DROP TABLE IF EXISTS `assay_report` /* generated by server */

检查binlog的脚本 - 229

mysqlbinlog --no-defaults --database=laboratory ./binlog.000074 > ~/74.sql

# at 1074009846
#260227 10:39:55 server id 1  end_log_pos 1074009890 CRC32 0x5b7eb4ae   Rotate to binlog.000075  pos: 4
SET @@SESSION.GTID_NEXT= 'AUTOMATIC' /* added by mysqlbinlog */ /*!*/;
DELIMITER ;
# End of log file
/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;

在243生成差异sql

mysqlbinlog --no-defaults --database=laboratory  --skip-gtids  --start-position=256983036 binlog.000074 --stop-position=287225397 binlog.000075 > all.sql

恢复sql

# 登录sql
mysql -u root -p
# 执行文件 (1.5G的all.sql最终执行了十几分钟，服务器是固态硬盘)
source /home/all.sql

最终效果

在下班前恢复完成数据库并准时下班🎉🎉🎉

ps：本次行动由gemini提供技术支持😂