vlambda博客
学习文章列表

前言

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

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

预备知识

SSH工具推荐

bin log 状态管理

在开始讲解bin log可以提供的两个功能之前，先要学会管理自己MySQL服务的bin log状态，并且通过修改参数对其进行控制。先来查看一下自己MySQL服务是否已经开启了bin log，可以看到我的二进制日志已经开启。如果你的没有，这里建议通过修改MySQL配置文件的方式将bin log声明为开启，然后重新启动MySQL服务即可。

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

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

bin log 数据文件

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

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

• ROW：数据文件中会记录每一行数据被修改的情况，这样就能保证在恢复数据或者主从复制时不会因为一些函数（如now()函数执行两次获取的时间是不一致的）导致数据不完全一致的情况，缺点是对于整张表的修改会导致大量数据插入到数据文件中。

• SRATEMENT：记录修改数据的SQL语句，和ROW相反，在数据同步时，某些情况下会出现不完全一致的情况。

• MIXED：混合使用上面两种记录模式，在一般情况下使用SRATEMENT，在特殊情况使用ROW。

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

数据恢复

准备数据

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

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

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

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

接下来我们通过 mysqlbinlog命令来查看bin log的数据文件（猜测表的变更被记录在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有所不同，下篇文章讲解）

模拟失误

数据恢复

要明确的是：借助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文件。

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

 
   
   
 

  
    
    
  
mysql> source ~/return.sql
 
   
   
 

结束语

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

我是白泽，一名后端程序员/学生党，建了一个春秋招备战/内推/闲聊群，欢迎大家加入。