【MySQL】记一次线上重大事故：二狗子竟然把线上数据库删了！！

我会带着你远行 2021-09-01 03:30 321阅读 0赞

## 写在前面 ##

> 估计二狗子这几天是大姨夫来了，心情很郁闷，情绪也很低落，工作的时候也有点心不在焉。让他发个版本，结果，一行命令下去把线上的数据库删了！你没听错：是删掉了线上的数据库！运营那边顿时炸了锅：怎么回事？系统不能访问了！什么情况啊？！很多客户都在投诉了！！
> 
> #  #
> 
> 尽管运营那边慌慌张张的不知所措，但是，我们作为技术人员还是要淡定，不就是删了数据库吗？没事，哥帮你搞定！
> 
> #  #
> 
> 如果文章对你有点帮助，请微信搜索并关注 **冰河技术** 微信公众号，点赞、在看、留言和转发，你的支持是我持续创作的最大动力！！

## 事件背景 ##

*  MySQL数据库每日零点自动全备
 *  某天上午9点，二狗子不小心drop了一个数据库
 *  我们需要通过全备的数据文件，以及增量的binlog文件进行数据恢复

## 主要思想与原理 ##

*  利用全备的sql文件中记录的CHANGE MASTER语句，binlog文件及其位置点信息，找出binlog文件增量的部分
 *  用mysqlbinlog命令将上述的binlog文件导出为sql文件，并剔除其中的drop语句
 *  通过全备文件和增量binlog文件的导出sql文件，就可以恢复到完整的数据

## 过程示意图 ##

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2wxMDI4Mzg2ODA0_size_16_color_FFFFFF_t_70_pic_center]

## 操作过程 ##

### 模拟数据 ###

CREATE TABLE `student` (
      `id` int(11) NOT NULL AUTO_INCREMENT,
      `name` char(20) NOT NULL,
      `age` tinyint(2) NOT NULL DEFAULT '0',
      PRIMARY KEY (`id`),
      KEY `index_name` (`name`)
    ) ENGINE=InnoDB AUTO_INCREMENT=8 DEFAULT CHARSET=utf8 
     
    mysql> insert student values(1,'zhangsan',20); 
    mysql> insert student values(2,'lisi',21); 
    mysql> insert student values(3,'wangwu',22);

### 全备命令 ###

# mysqldump -uroot -p -B -F -R -x --master-data=2 test|gzip >/server/backup/test_$(date +%F).sql.gz

参数说明：

*  \-B 指定数据库
 *  \-F 刷新日志
 *  \-R 备份存储过程等
 *  \-x 锁表
 *  –master-data 在备份语句里添加CHANGE MASTER语句以及binlog文件及位置点信息

### 继续插入数据并删库 ###

mysql> insert student values(4,'xiaoming',20);
    mysql> insert student values(5,'xiaohong',20);

在插入数据的时候我们模拟误操作，删除test数据库。

mysql> drop database test;

此时，全备之后到误操作时刻之间，用户写入的数据在binlog中，需要恢复出来。

### 查看全备之后新增的binlog文件 ###

# cd /server/backup/
    # ls
    test_2020-08-19.sql.gz
    # gzip -d test_2020-08-19.sql.gz 
    # grep CHANGE test_2020-08-19.sql 
    -- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000003', MASTER_LOG_POS=107;

这是全备时刻的binlog文件位置，即mysql-bin.000003的107行，因此在该文件之前的binlog文件中的数据都已经包含在这个全备的sql文件中了

### 移动binlog文件，并读取sql，剔除其中的drop语句 ###

# cp /data/3306/mysql-bin.000003 /server/backup/
    # mysqlbinlog -d test mysql-bin.000003 >mysql-bin.000003.sql

接下来，使用vim编辑mysql-bin.000003.sql文件，剔除drop语句

**注意：在恢复全备数据之前必须将该binlog文件移出，否则恢复过程中，会继续写入语句到binlog，最终导致增量恢复数据部分变得比较混乱**

### 恢复数据 ###

# mysql -uroot -p < test_2020-08-19.sql 
    # mysql -uroot -p -e "select * from test.student;"
    +----+----------+-----+
    | id | name     | age |
    +----+----------+-----+
    |  1 | zhangsan |  20 |
    |  2 | lisi     |  21 |
    |  3 | wangwu   |  22 |
    +----+----------+-----+

此时恢复了全备时刻的数据，然后使用mysql-bin.000003.sql文件恢复全备时刻到删除数据库之间，新增的数据。

# mysql -uroot -p test < mysql-bin.000003.sql 
    # mysql -uroot -p -e "select * from test.student;"
    +----+----------+-----+
    | id | name     | age |
    +----+----------+-----+
    |  1 | zhangsan |  20 |
    |  2 | lisi     |  20 |
    |  3 | wangwu   |  20 |
    |  4 | xiaoming |  20 | 
    |  5 | xiaohong |  20 |
    +----+----------+-----+

此时，整个恢复过程结束，是不是很简单呢？没错，就是这么简单！！

## 总结 ##

*  适合人为SQL语句造成的误操作或者没有主从复制等的热备情况宕机时的修复。
 *  恢复条件要全备和增量的所有数据。
 *  恢复时建议对外停止更新，即禁止更新数据库。
 *  先恢复全量，然后把全备时刻点以后的增量日志，按顺序恢复成SQL文件，然后把文件中有问题的SQL语句删除（也可通过时间和位置点），再恢复到数据库。

## 重磅福利 ##

关注「 **冰河技术** 」微信公众号，后台回复 “**设计模式**” 关键字领取《**深入浅出Java 23种设计模式**》PDF文档。回复“**Java8**”关键字领取《**Java8新特性教程**》PDF文档。回复“**限流**”关键字获取《**亿级流量下的分布式限流解决方案**》PDF文档，三本PDF均是由冰河原创并整理的超硬核教程，面试必备！！

**好了，今天就聊到这儿吧！别忘了点个赞，给个在看和转发，让更多的人看到，一起学习，一起进步！！**

## 写在最后 ##

> 如果你觉得冰河写的还不错，请微信搜索并关注「 **冰河技术** 」微信公众号，跟冰河学习高并发、分布式、微服务、大数据、互联网和云原生技术，「 **冰河技术** 」微信公众号更新了大量技术专题，每一篇技术文章干货满满！不少读者已经通过阅读「 **冰河技术** 」微信公众号文章，吊打面试官，成功跳槽到大厂；也有不少读者实现了技术上的飞跃，成为公司的技术骨干！如果你也想像他们一样提升自己的能力，实现技术能力的飞跃，进大厂，升职加薪，那就关注「 **冰河技术** 」微信公众号吧，每天更新超硬核技术干货，让你对如何提升技术能力不再迷茫！

![20200716220443647.png_pic_center][]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2wxMDI4Mzg2ODA0_size_16_color_FFFFFF_t_70_pic_center]: /images/20210901/6e62adda091542e09f8f417e8294b8cb.png
[20200716220443647.png_pic_center]: /images/20210901/774ab495b3fe42cd9efaffdacbfe3e0a.png