MySQL通过bin log恢复数据｜手撕MySQL｜对线面试官

MySQL通过bin log恢复数据｜手撕MySQL｜对线面试官

前言

作为**《手撕MySQL》系列的第二篇文章，今天介绍一下MySQL的二进制日志（bin log），注意不要和MySQL的InnoDB存储引擎特有的重写日志（redo log）混淆，bin log是记录所有数据库表数据及表结构**变更的二进制日志（不会记录查询操作），借助这个日志可以实现：​​数据恢复​​​和​​主从复制​​（不难理解，因为所有涉及变更的操作都记录了下来，可以追溯）。

这篇文章侧重于讲解使用bin log进行数据恢复，下一篇文章讲解主从复制。

预备知识

SSH工具推荐

接下来会频繁在控制台终端中输入命令，因此推荐一款开源免费的ssh客户端electerm：​​github.com/electerm/el…​​

bin log 状态管理

以Linux系统为例，MySQL数据库是按照 ​​/etc/my-f​​​ —— ​​/etc/mysql/my-f​​​ —— ​​/usr/local/mysql/etc/my-f​​​ —— ​​~/.my-f​​ 的顺序读取配置文件的，且如果出现参数重复设置则后一个配置文件中参数会覆盖前者。如果你的MySQL服务没有配置文件，那就直接自己创建一个，放在上面某个位置之一，然后在创建的配置文件中输入你从网上搜到的设置bin log开启的配置代码，重启MySQL服务即可。

现在假设你已经开启了MySQL的二进制日志，如下：

mysql> show variables like '%log_bin%';

bin log 数据文件

观察上面的查询结果，可以看到两个路径变量：​​log_bin_basename​​​和​​log_bin_index​​​，分别表示bin log开启后，数据文件的生成位置（​​/usr/local/mysql/data/​​​）和文件名规则（binlog.xxxxx1、binlog.xxxxx2以此类推），以及索引文件​​binlog.index​​，其中存放着bin log数据文件列表。

# 查看MySQL数据文件列表（大部分MySQL数据文件都在这个路径下，下面展示部分，主要是bin log相关的数据文件和索引文件）

# 查看bin log索引文件内容（完全对应上面列出的三个数据文件）

既然上面说到，bin log记录所有对数据库的更改操作，**那么它是将SQL语句记录在数据文件中还是将改动之后的行结果记录下来呢？**这里有三种记录模式：

ROW：数据文件中会记录每一行数据被修改的情况，这样就能保证在恢复数据或者主从复制时不会因为一些函数（如now()函数执行两次获取的时间是不一致的）导致数据不完全一致的情况，缺点是对于整张表的修改会导致大量数据插入到数据文件中。SRATEMENT：记录修改数据的SQL语句，和ROW相反，在数据同步时，某些情况下会出现不完全一致的情况。MIXED：混合使用上面两种记录模式，在一般情况下使用SRATEMENT，在特殊情况使用ROW。

但是，新版本MySQL的ROW模式已经进行了优化，对于表结构的修改会以STATEMENT模式记录，而对于记录的修改则会在数据文件中记录所有的行的变更。因此，ROW模式是bin log默认的工作模式。

mysql> show variables like 'binlog_format';

数据恢复

准备数据

**Talk is cheap，show me the code！**我知道你已经迫不及待想体验bin log的数据恢复了，那就让我们开始吧～

为了方便展示，我们在MySQL登录态下执行​​flush logs​​命令，可以生成一个新的日志文件（为了将后面操作数据库的命令单独放在一个新的数据文件中方便查看）

# 生成新的二进制数据文件（序号增加）mysql> flush logs;# 查看当前所有二进制数据文件mysql> show binary logs;

因为我执行了两次flush log命令，因此以此生成了两个新的二进制数据文件，而且明显可以看到这两个数据文件很小，因为还没有新的修改表的操作被记录下来。

接下来我们建立一个测试数据库：​​test_database​​，然后创建一张用户表，并且为其插入几条测试数据。

# 创建user表CREATE TABLE `user` (`id` int(11) NOT NULL AUTO_INCREMENT,`username` VARCHAR(255) NOT NULL,PRIMARY KEY (`id`)) ENGINE = INNODB DEFAULT CHARSET=utf8;# 插入测试用户数据INSERT INTO user (id, username) VALUES (null, 'AAA');INSERT INTO user (id, username) VALUES (null, 'BBB');INSERT INTO user (id, username) VALUES (null, 'CCC');# 查询测试SELECT * FROM user

接下来我们通过​​mysqlbinlog​​命令来查看bin log的数据文件（猜测表的变更被记录在binlog.000010二进制文件中），这里展示一部分。

sudo mysqlbinlog /usr/local/mysql/data/binlog.000010

下面是binlog.000010文件的部分内容，我们找到了建​​user表​​的语句（上面说了，新版MySQL的ROW数据记录模式对于表结构的更改是STATEMENT形式的），下面是数据文件中一些重要的字段解释：

第一个at表示一个事件的起始位置pos，中间的是此次事件的二进制数据，而末尾的at表示下一个事件开始位置pos（也就是当前时间的结束位置pos）220303 17:59:37 server id 1 表示server 1执行该事件的时间exec_time 表示执行时间（具体时间在主从复制时master和slave有所不同，下篇文章讲解）

# 这个mysqlbinlog命令还可以添加参数，如指定查询开始pos到结束pos之间的数据，Google一下～sudo mysqlbinlog /usr/local/mysql/data/binlog.000010# 当然，不借助mysqlbinlog命令，在mysql登录状态下也是可以直接查询bin log数据文件内容的，测试如下：mysql> show binlog events in 'binlog.000010' from 447 limit

模拟失误

# 失误删除id为1的用户DELETE FROM user where id=1# 又插入两个用户INSERT INTO user (id, username) VALUES (null, 'DDD');INSERT INTO user (id, username) VALUES (null, 'EEE');

数据恢复

要明确的是：借助bin log二进制日志文件进行数据恢复的本质，是重新执行两个pos区间内的SQL**（所以上面才花了较大篇幅讲解查看二进制文件，为的是学会定位pos点，也就是at后面那个数字）**

首先通过mysql命令查看binlog.000010数据文件

mysql> show binlog events in 'binlog.000010';

这里要找到两个pos点，一个是user表建立的pos：447，另一个是执行delete操作之前的pos，这里要求结束的pos不能直接选择delete_rows操作的pos：1864，而是要选择它前一个commit事件的下一个pos：1636（否则会出现警告⚠️）

使用mysqlbinlog命令生成pos为447—1636之间的SQL文件（上面说了数据恢复的本质是重新执行两个pos区间内的SQL语句），通过下面的命令，生成了一个return.sql文件。

sudo mysqlbinlog --start-position=447 --stop-position=1636 /usr/local/mysql/data/binlog.000010 > return.sql

执行return.sql文件（相当于又执行了一遍这个区间的SQL语句），进行数据恢复！大功告成！删除的AAA回来了！！不用被开除了！！

mysql> source

结束语

本篇文章简单讲述了利用bin log进行数据恢复的案例，并且花费了较大篇幅讲解一些bin log的基础知识，为的是为后续讲解利用bin log进行主从复制打下基础，希望阅读本文之后，您感到对二进制日志的理解在八股文的基础之上，更进一步了。

​

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。