如何删库跑路？教你使用Binlog日志恢复误删的MySQL数据

时间 2020-12-06

标签 html mysql 程序员面试算法 spring sql 数据库 ubuntu 后端栏目 MySQL 繁體版

原文原文链接

前言

“删库跑路”是程序员常常谈起的话题，今天，我就要教你们如何删！库！跑！路！
html

开个玩笑，今天文章的主题是如何使用Mysql内置的Binlog日志对误删的数据进行恢复，读完本文，你可以了解到：mysql

MySQL的binlog日志是什么？一般是用来干什么的？
模拟一次误删数据的操做，而且使用binlog日志恢复误删的数据。

写这篇文章的初衷，是有一次我真的险些把测试数据库的一张表给删除了，当时吓出一身冷汗。缘由是因为Spring JPA的配置中，有一个spring.jpa.properties.hibernate.hbm2ddl.auto=create-drop，其用途是每次加载hibernate时根据model类生成表，可是sessionFactory一关闭,表就自动删除。，这个可不能随便配置上去，直接就把你原来存在的表给drop了！程序员

好了，回归正题，这篇文章就是想让你们放心，MySQL就算进行了误删操做，也基本都可以抢救回来。尤为是大公司内，数据可不是你想删就能删掉的，有无数权限/备份阻拦着你。面试

正文

Binlog介绍

binlog是记录全部数据库表结构变动（例如CREATE、ALTER TABLE…）以及表数据修改（INSERT、UPDATE、DELETE…）的二进制日志。
binlog不会记录SELECT和SHOW这类操做，由于这类操做对数据自己并无修改，但你能够经过查询通用日志来查看MySQL执行过的全部语句。算法

看了上面binlog的定义，你们也应该能大体推理出binlog的三大用途：spring

恢复数据：今天要说的重点
数据库复制：主从数据库是经过将binlog传给从库，从库有两个线程，一个I/O线程，一个SQL线程，I/O线程读取主库传过来的binlog内容并写入到relay log,SQL线程从relay log里面读取内容，写入从库的数据库。
审计：用户能够经过二进制日志中的信息来进行审计，判断是否有对数据库进行注入***。

因此说，想要可以恢复数据，首先，你得打开Mysql的binlog，在日常你本身安装的单机Mysql中，默认状况下不会开启。下面就一步步地实践下如何开启你服务器上的Binlog日志。sql

在MySQL中开启Binlog

首先进入数据库控制台，运行指令：数据库

mysql> show variables like'log_bin%';
+---------------------------------+-------+
| Variable_name                   | Value |
+---------------------------------+-------+
| log_bin                         | OFF   |
| log_bin_basename                |       |
| log_bin_index                   |       |
| log_bin_trust_function_creators | OFF   |
| log_bin_use_v1_row_events       | OFF   |
+---------------------------------+-------+
5 rows in set (0.00 sec)

能够看到咱们的binlog是关闭的，都是OFF。接下来咱们须要修改Mysql配置文件，执行命令：ubuntu

sudo vi /etc/mysql/mysql.conf.d/mysqld.cnf

在文件末尾添加：后端

log-bin=/var/lib/mysql/mysql-bin

保存文件，重启mysql服务：

sudo service mysql restart

重启完成后，查看下mysql的状态：

systemctl status mysql.service

这时，若是你的mysql版本在5.7或更高版本，就会报错：

Jan 06 15:49:58 VM-0-11-ubuntu mysqld[5930]: 2020-01-06T07:49:58.190791Z 0 [Warning] Changed limits: max_open_files: 1024 (requested 5000)
Jan 06 15:49:58 VM-0-11-ubuntu mysqld[5930]: 2020-01-06T07:49:58.190839Z 0 [Warning] Changed limits: table_open_cache: 431 (requested 2000)
Jan 06 15:49:58 VM-0-11-ubuntu mysqld[5930]: 2020-01-06T07:49:58.359713Z 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (se
Jan 06 15:49:58 VM-0-11-ubuntu mysqld[5930]: 2020-01-06T07:49:58.361395Z 0 [Note] /usr/sbin/mysqld (mysqld 5.7.28-0ubuntu0.16.04.2-log) starting as process 5930 ...
Jan 06 15:49:58 VM-0-11-ubuntu mysqld[5930]: 2020-01-06T07:49:58.363017Z 0 [ERROR] You have enabled the binary log, but you haven't provided the mandatory server-id. Please refer to the proper server
Jan 06 15:49:58 VM-0-11-ubuntu mysqld[5930]: 2020-01-06T07:49:58.363747Z 0 [ERROR] Aborting
Jan 06 15:49:58 VM-0-11-ubuntu mysqld[5930]: 2020-01-06T07:49:58.363922Z 0 [Note] Binlog end
Jan 06 15:49:58 VM-0-11-ubuntu mysqld[5930]: 2020-01-06T07:49:58.364108Z 0 [Note] /usr/sbin/mysqld: Shutdown complete
Jan 06 15:49:58 VM-0-11-ubuntu systemd[1]: mysql.service: Main process exited, code=exited, status=1/FAILURE

You have enabled the binary log, but you haven't provided the mandatory server-id. Please refer to the proper server

以前咱们的配置，对于5.7如下版本应该是能够的。但对于高版本，咱们须要指定server-id。

若是你不是分布式的部署Mysql，这个server-id随机给个数字就能够。

server-id=123454

模拟删除数据并恢复

首先新建数据库mytest，新建一张表table1，结构见下方SQL代码

CREATE DATABASE `test` ;

USE `test`;

DROP TABLE IF EXISTS `table1`;

CREATE TABLE `table2` (
  `id` int(11) DEFAULT NULL,
  `name` varchar(20) DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

插入两条数据，分别是 (1,'A'),(2,'B')

INSERT INTO `table1` VALUES (1,'A'),(2,'B');

咱们看一下binlog日志的状态，使用show master status

mysql> show master status
    -> ;
+------------------+----------+--------------+------------------+-------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+-------------------+
| mysql-bin.000001 |      690 |              |                  |                   |
+------------------+----------+--------------+------------------+-------------------+
1 row in set

binlog日志特征：每当咱们重启MySQL一次，会自动生成一个binlog文件，固然，咱们也能够手动的来刷新binlog文件，经过 flush logs,一样会新建立一个binlog文件。实际上当服务器在重启时，也会调用flush logs操做。

上图代码中能够看到，如今咱们正在使用 mysql-bin.0000001 ，而且这个文件如今正在记录到690行。

而后，使用flush logs来主动刷新一次binlog

mysql> flush logs;
Query OK, 0 rows affected

mysql> show master status
    -> ;
+------------------+----------+--------------+------------------+-------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+-------------------+
| mysql-bin.000002 |      154 |              |                  |                   |
+------------------+----------+--------------+------------------+-------------------+
1 row in set

能够看到，如今日志文件在 mysql-bin.000002 文件中，位置为154。也就是咱们主动刷新了一次binlog，生成了新的000002，而000001则已经归档了，不会再写入新的日志进去了。

接下来咱们在插入两条数据

insert into table1 values (3,'C');
insert into table1 values (4,'D');
mysql> select * from table1;
+----+----+
| id |name|
+----+----+
|  1 | A  |
|  2 | B  |
|  3 | C  |
|  4 | D  |
+----+----+

这时候咱们已经有了四条数据，咱们再次flush logs，把mysql-bin.000002日志存档，开启新的mysql-bin.000003日志，这样，每次咱们插入的数据彼此独立。实际状况下，binlog会比较复杂，这里也是作了简化，为了理解更方便。

mysql> flush logs;
Query OK, 0 rows affected

mysql> show master status;
+------------------+----------+--------------+------------------+-------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+-------------------+
| mysql-bin.000003 |      154 |              |                  |                   |
+------------------+----------+--------------+------------------+-------------------+
1 row in set

而后咱们删除id为4的数据（4，D），而且再次刷新binlog，如此一来，binlog.000003里面只有一条删除操做。

mysql> delete from table1 where id = 4;
Query OK, 1 row affected

mysql> show master status;
+------------------+----------+--------------+------------------+-------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+-------------------+
| mysql-bin.000003 |      423 |              |                  |                   |
+------------------+----------+--------------+------------------+-------------------+
1 row in set

mysql> flush logs;
Query OK, 0 rows affected

mysql> show master status;
+------------------+----------+--------------+------------------+-------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+-------------------+
| mysql-bin.000004 |      154 |              |                  |                   |
+------------------+----------+--------------+------------------+-------------------+
1 row in set

让咱们来好好观察下mysql-bin.00002和mysql-bin00003两个binlog，使用命令：show binlog events in 'mysql-bin.000003'

mysql> show binlog events in 'mysql-bin.000003';
+------------------+-----+----------------+-----------+-------------+--------------------------------------------------------+
| Log_name         | Pos | Event_type     | Server_id | End_log_pos | Info                                                   |
+------------------+-----+----------------+-----------+-------------+--------------------------------------------------------+
| mysql-bin.000003 |   4 | Format_desc    |    123456 |         123 | Server ver: 5.7.28-0ubuntu0.16.04.2-log, Binlog ver: 4 |
| mysql-bin.000003 | 123 | Previous_gtids |    123456 |         154 |                                                        |
| mysql-bin.000003 | 154 | Anonymous_Gtid |    123456 |         219 | SET @@SESSION.GTID_NEXT= 'ANONYMOUS'                   |
| mysql-bin.000003 | 219 | Query          |    123456 |         293 | BEGIN                                                  |
| mysql-bin.000003 | 293 | Table_map      |    123456 |         343 | table_id: 108 (test.table1)                              |
| mysql-bin.000003 | 343 | Delete_rows    |    123456 |         392 | table_id: 108 flags: STMT_END_F                        |
| mysql-bin.000003 | 392 | Xid            |    123456 |         423 | COMMIT /* xid=39 */                                    |
+------------------+-----+----------------+-----------+-------------+--------------------------------------------------------+
7 rows in set

mysql> show binlog events in 'mysql-bin.000002';
+------------------+-----+----------------+-----------+-------------+--------------------------------------------------------+
| Log_name         | Pos | Event_type     | Server_id | End_log_pos | Info                                                   |
+------------------+-----+----------------+-----------+-------------+--------------------------------------------------------+
| mysql-bin.000002 |   4 | Format_desc    |    123456 |         123 | Server ver: 5.7.28-0ubuntu0.16.04.2-log, Binlog ver: 4 |
| mysql-bin.000002 | 123 | Previous_gtids |    123456 |         154 |                                                        |
| mysql-bin.000002 | 154 | Anonymous_Gtid |    123456 |         219 | SET @@SESSION.GTID_NEXT= 'ANONYMOUS'                   |
| mysql-bin.000002 | 219 | Query          |    123456 |         293 | BEGIN                                                  |
| mysql-bin.000002 | 293 | Table_map      |    123456 |         343 | table_id: 108 (test.table1)                              |
| mysql-bin.000002 | 343 | Write_rows     |    123456 |         390 | table_id: 108 flags: STMT_END_F                        |
| mysql-bin.000002 | 390 | Xid            |    123456 |         421 | COMMIT /* xid=34 */                                    |
| mysql-bin.000002 | 421 | Anonymous_Gtid |    123456 |         486 | SET @@SESSION.GTID_NEXT= 'ANONYMOUS'                   |
| mysql-bin.000002 | 486 | Query          |    123456 |         560 | BEGIN                                                  |
| mysql-bin.000002 | 560 | Table_map      |    123456 |         610 | table_id: 108 (test.table1)                              |
| mysql-bin.000002 | 610 | Write_rows     |    123456 |         659 | table_id: 108 flags: STMT_END_F                        |
| mysql-bin.000002 | 659 | Xid            |    123456 |         690 | COMMIT /* xid=35 */                                    |
| mysql-bin.000002 | 690 | Rotate         |    123456 |         737 | mysql-bin.000003;pos=4                                 |
+------------------+-----+----------------+-----------+-------------+--------------------------------------------------------+
13 rows in set

虽然有不少看似复杂的指令，可是仍是不难看出，在02里，有两条写操做，03里有一条删除操做。

一条插入操做的完整日志是这样：

| mysql-bin.000002 | 154 | Anonymous_Gtid |    123456 |         219 | SET @@SESSION.GTID_NEXT= 'ANONYMOUS'                   |
| mysql-bin.000002 | 219 | Query          |    123456 |         293 | BEGIN                                                  |
| mysql-bin.000002 | 293 | Table_map      |    123456 |         343 | table_id: 108 (test.table1)                              |
| mysql-bin.000002 | 343 | Write_rows     |    123456 |         390 | table_id: 108 flags: STMT_END_F                        |
| mysql-bin.000002 | 390 | Xid            |    123456 |         421 | COMMIT /* xid=34 */                                    |

咱们的目的是恢复误删的数据，其实就是将binlog.000002日志的两条插入记录重演一遍，而不须要取理会binlog.000003的操做（由于删除是一个误操做）
因此如今能理解为何咱们频繁刷新binlog了吧，固然，在实际的线上环境中，咱们确定须要将binlog导出后，仔细筛选出误操做，并将其排除，以后再运行binlog。

在本文中，咱们只作一个恢复两条插入语句的操做，执行语句：

sudo mysqlbinlog /var/lib/mysql/mysql-bin.000002 --start-position 154 --stop-position 690 | mysql -uroot -p mytest

注意：这里填写的路径/var/lib/mysql/mysql-bin.000002须要具体到你的binlog目录，网上大部分文章只写到mysql-bin.000002，若是你不在目录里，mysqlbinlog命令并不会自动定位binlog所在路径。

参数描述：

--start-datetime：从二进制日志中读取指定等于时间戳或者晚于本地计算机的时间

--stop-datetime：从二进制日志中读取指定小于时间戳或者等于本地计算机的时间 取值和上述同样

--start-position：从二进制日志中读取指定position 事件位置做为开始。

--stop-position：从二进制日志中读取指定position 事件位置做为事件截至

执行成功后，再次查看表table1，能够看到两条新的id=3和4的数据被插入了进来。恢复成功了。

mysql> select * from table1;
+----+----+
| id |name|
+----+----+
|  1 | A  |
|  2 | B  |
|  3 | C  | 
|  3 | C  |
|  4 | D  |
+----+----+
6 rows in set

延伸思考

Binlog在什么状况下没法恢复数据？

结语

删库跑路不用怕，其余开发运维都等着恢复你的数据呢，多好的练手机会是否是。

固然，看完binlog日志恢复数据的原理，但愿你们之后在按期备份数据库的脚本里，也可以加上刷新binlog日志的命令，这样一旦某天丢失数据，能够将当天binlog数据单独拿出来还原，作到清晰可辨，也加快恢复效率。

参考

https://www.cnblogs.com/rjzheng/p/9721765.html

http://www.javashuo.com/article/p-mtfmpaby-du.html

https://www.jianshu.com/p/564fcc2b5e31

http://www.javashuo.com/article/p-sbrfltcr-z.html

关注我

我是一名后端开发工程师。

主要关注后端开发，数据安全，爬虫，物联网，边缘计算等方向，欢迎交流。

各大平台均可以找到我

微信公众号：后端技术漫谈
Github：@qqxx6661
CSDN：@后端技术漫谈
知乎：@后端技术漫谈
简书：@后端技术漫谈
掘金：@后端技术漫谈

原创博客主要内容

后端开发相关技术文章
Java面试知识点复习全手册
设计模式/数据结构
Leetcode/剑指offer 算法题解析
SpringBoot/SpringCloud 入门实战系列
爬虫相关技术文章
逸闻趣事/好书分享/我的兴趣

我的公众号：后端技术漫谈

公众号：后端技术漫谈.jpg若是文章对你有帮助，不妨收藏，投币，转发，在看起来~