MySQL 经过 binlog 恢复数据

目的

经过了解 binlog 日志的相关配置，简单掌握经过 binlog 对数据库进行数据恢复操做；

mysql 日志文件

任何成熟软件都会有一套成熟的日志系统，当软件出现问题时，这些日志就是查询问题来源的宝库。一样，mysql 也不例外，也会有一系列日志记录 mysql 的运行状态。

mysql 主要有如下几种日志：

• 错误日志：记录 mysql 运行过程当中的错误信息
• 通常查询日志：记录mysql正在运行的语句，包括查询、修改、更新等的每条 sql
• 慢查询日志：记录查询比较耗时的 SQL 语句
• binlog 日志：记录数据修改记录，包括建立表、数据更新等

这些日志均须要在 my.cnf 文件进行配置，若是不知道 mysql 的配置文件路径，可使用 mysql 命令进行查找，

mysql --verbose --help|grep -A 1 'Default options’ #该命令会罗列出my.cnf 顺序查找的路径。

binlog 日志

binlog 就是 binary log，二进制日志文件，记录全部数据库更新语句，包括表更新和记录更新，即数据操纵语言(DML)，binlog 主要用于数据恢复和配置主从复制等；

• 数据恢复：当数据库误删或者发生不可描述的事情时，能够经过 binlog 恢复到某个时间点的数据。
• 主从复制：当有数据库更新以后，主库经过 binlog 记录并通知从库进行更新，从而保证主从数据库数据一致；

mysql 按照功能分为服务层模块和存储引擎层模块，服务层负责客户端链接、SQL 语句处理优化等操做，存储引擎层负责数据的存储和查询；binlog 属于服务层模块的日志，即引擎无关性，全部数据引擎的数据更改都会记录binlog日志。当数据库发生崩溃时，若是使用InnoDB 引擎，binlog 日志还能够检验 InnoDB 的 redo 日志的 commit 状况。

binlog 日志开启

日志开启方式：

一、添加配置

log_bin=ON
log_bin_basename=/path/bin-log
log_bin_index=/path/bin-log.index

二、仅仅设置log-bin参数

log-bin=/path/bin-log

当开启 binlog 日志以后，mysql 会建立一个 log_bin_index 指定的 .index 文件和多个二进制日志文件，index 中按顺序记录了mysql使用的全部 binlog 文件。binlog 日志则会以指定的名称(或默认值) 加自增的数字做为后缀，ex：bin-log.000001，当发生下述三种状况时，binlog 日志便会进行重建:

文件大小达到 max_binlog_size 参数的值
执行 flush logs 命令
重启 mysql 服务

binlog 日志格式

经过参数 binlog_format 参数的值，能够设置 binlog 的格式，可选值有 statement、row、mixed

* statement 格式：记录数据库执行的原始 SQL 语句
  * row 格式：记录具体的行的修改，这个为目前默认值
  * mixed 格式：由于上边两种格式各有优缺点，因此就出现了 mixed 格式

binlog 日志查看工具：mysqlbinlog

由于 binlog 是二进制文件，不能像其余文件同样，直接打开查看。但 mysql 提供了binlog 查看工具 mysqlbinlog，能够解析二进制文件。固然不一样格式的日志解析结果是不同的；

1. statement 格式日志，执行 mysqlbinlog  /path/bin-log.000001，能够直接看到原始执行的 SQL 语句
2. row格式日志，则可读性没有那么好，但仍可经过参数使文档更加可读 mysqlbinlog -v  /path/bin-log.000001

mysqlbinlog两对很是重要的参数

1. --start-datetime  --stop-datetime 解析某一个时间段内的binlog；
  2. --start-position  --stop-position   解析在两个position之间的binlog；

使用 binlog 恢复数据：

使用 binlog 恢复数据，本质上就是经过 binlog 找到全部 DML 操做，去掉错误的 SQL 语句，而后重走一遍长征路，就能够将数据恢复；

线下实操：

1. 建立数据表并插入初始值

CREATE TABLE `users` (
              `id` int(11) unsigned NOT NULL AUTO_INCREMENT,
              `name` varchar(255) DEFAULT NULL,
              `age` int(8) DEFAULT NULL,
              PRIMARY KEY (`id`)
     ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
     INSERT INTO `users` (`id`, `name`, `age`)
        VALUES
            (null, '姓名一', 5);

1. 找到上一次全量备份的数据库和binlog的position(ps：固然也能够经过时间进行恢复)。此处以目前状态做为备份的初始值，

mysqldump -uroot -p T > /path/xxx.sql;   # 备份数据库
    show master status;   # 查看当前的position位置，此时值为154

1. 插入多条记录

INSERT INTO `users` (`id`, `name`, `age`)
  VALUES
     (null, '姓名二', 13),
     (null, '姓名三', 14),
     (null, '姓名四', 15),
     (null, '姓名五', 16),
     (null, '姓名六', 17);

1. 进行误操做，而且在误操做以后又插入几条数据

update users set age = 5；
 INSERT INTO `users` (`id`, `name`, `age`)
 VALUES
    (null, '姓名七', 16),
    (null, '姓名八', 18);

1. 发现误操做以后，进行数据恢复，首先中止 mysql 对外的服务，利用备份数据恢复到上次数据；
2. 经过 mysqlbinlog 命令对二进制文件进行分析，分析发现

误操做发生在position为706位置，且上次正常操做的结束位置在513
    在1152到结尾位置有正常执行的SQL执行

1. 经过 mysqlbinlog 命令从 binlog 日志中导出可执行的 SQL 文件，并将数据导入到mysql

mysqlbinlog --start-position=154  --stop-position=513  bin-log.000001 > /path/bak.sql;
 mysql -uroot -p < /path/bak.sql;

1. 跳过错误的更新语句，再经过步骤7的逻辑把后续正常语句从新跑一遍，完成数据恢复工做

小结

不管什么时间，数据库发生崩溃都会使人愁眉紧锁，心烦意乱。binlog能够说是在各类状况下，数据库崩溃、数据丢失以后的一粒后悔药，本文经过线下环境，简单的对数据库进行了一次数据恢复实验，若有不对，还请指教

参考文章

http://www.ywnds.com/?p=12839
https://zhuanlan.zhihu.com/p/...