머리말

프로그래머 "도보 삭제 라이브러리는"종종 화제, 오늘 이야기, 나는 어떻게 삭제하는 방법을 가르 칠거야! 도서관! 실행! 도로!

농담, 오늘의 기사의 주제는 내장, 실수로 삭제 된 데이터를 복구이 기사를 읽고에 바이너리 로그 MySQL의 로그, 당신은 배울 수 있습니다 사용하는 방법입니다 :

MySQL의 바이너리 로그 로그는 무엇인가? 보통 그들은 어떻게 사용?
시뮬레이션 된 동작은 실수로 데이터를 삭제하고, 실수로 삭제 된 데이터를 복원하는 바이너리 로그 기록 사용.

이 기사를 쓰고의 원래 의도는, 정말 거의 테스트 데이터베이스 테이블에 다음 식은 땀을 삭제하는 시간이있다. 그 이유는 스프링 JPA 구성에, 거기입니다 때문이다 spring.jpa.properties.hibernate.hbm2ddl.auto=create-drop, 그 목적은 每次加载hibernate时根据model类生成表，但是sessionFactory一关闭,表就自动删除。,이 구성은 그냥 드롭하기 위해 직접 기존 테이블을 넣어까지 갈 수 없어!

음, 주제 다시는이 문서가하는 것입니다 안심 모든 사람들하려는 작업이 실수로 삭제 된 경우에도, MySQL은, 그들은 기본적으로 회수 할 수 있습니다. 특히 대기업 내에서, 당신은 삭제할 수 없습니다 데이터를 삭제하려면, 셀 수없이 많은있다 권한 / 백업 정지 당신은.

본문

바이너리 로그 소개

바이너리 로그 데이터베이스 테이블은 모든 구조적 변화 (예를 들면, CREATE TABLE ALTER ...)과 테이블 데이터 변형 (삽입, 업데이트, 삭제 ...) 바이너리 로그를 기록한다.
바이너리 로그 SELECT를 기록하고 이러한 유형의 조작 SHOW 데이터에 이러한 작업 자체가 수정되지 않기 때문에,하지만 당신은 MySQL이 일반 로그를 조회하여 실행하는 모든 문을 볼 수 없습니다.

우리는 대략 세 가지 목적을 바이너리 로그 추론 할 수 있어야한다, 위의 정의 바이너리 로그 읽기 :

데이터 복구 : 오늘 말씀의 초점
데이터베이스 복제 : 마스터 - 슬레이브 데이터베이스는 두 개의 스레드, 하나의 I / O 쓰레드는 SQL 쓰레드가 도서관에서의 I / O 쓰레드는 릴레이 컨텐츠 및 쓰기를 건너 바이너리 로그의 주요 라이브러리를 읽고, 라이브러리의 바이너리 로그를 통과 로그, SQL 스레드는 라이브러리에서 데이터베이스로, 내부에서 릴레이 로그의 내용을 읽습니다.
감사 : 사용자는 바이너리 로그 정보에 의해 감사 할 수 데이터베이스 주입 공격 여부를 결정합니다.

所以说，想要能够恢复数据，首先，你得打开Mysql的binlog，在平常你自己安装的单机Mysql中，默认情况下不会开启。下面就一步步地实践下如何开启你服务器上的Binlog日志。

在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配置文件，执行命令：

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

https://blog.csdn.net/king_kgh/article/details/74890381

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

https://blog.csdn.net/king_kgh/article/details/74833539

关注我

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

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

各大平台都可以找到我

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

原创博客主要内容

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

个人公众号：后端技术漫谈

公众号：后端技术漫谈.jpg

如果文章对你有帮助，不妨收藏，投币，转发，在看起来~

后端技术漫谈博客专家

发布了259 篇原创文章 · 获赞 136 · 访问量 38万+

他的留言板关注

[40] 사용하는 바이너리 로그 발 라이브러리 로그 데이터를 실수로 삭제 MySQL의 복구

머리말

본문