惊心动魄的恢复误删mysql数据

简介

今天上午由于手jian，不小心点了phpmyadmin中的一个删除键，把一行数据game over了。
由于平时偷懒，就喜欢用phpmyadmin的可视化界面，今天终于得到惩罚。

就是这个按钮

想起这是一行内容很多的数据，让我重写，肯定不愿意啊。所以就百度恢复mysql数据的方法。下面是学习笔记。

首先我用的是binlog日志恢复数据。

1.那么什么是binlog:

MySQL的二进制日志binlog可以说是MySQL最重要的日志，它记录了所有的DDL和DML语句（除了数据查询语句select），以事件形式记录，还包含语句所执行的消耗的时间，MySQL的二进制日志是事务安全型的。=======================================================
DDL - Data Definition Language 数据库定义语言
主要的命令有CREATE、ALTER、DROP等，DDL主要是用在定义或改变表（TABLE）的结构，数据类型，表之间的链接和约束等初始化工作上，他们大多在建立表时使用。
DML - Data Manipulation Language 数据操纵语言
主要的命令是SELECT、UPDATE、INSERT、DELETE，就象它的名字一样，这4条命令是用来对数据库里的数据进行操作的语言

binlog日志有两个最重要的使用场景
1）MySQL主从复制：MySQL Replication在Master端开启binlog，Master把它的二进制日志传递给slaves来达到master-slave数据一致的目的。
2）数据恢复，通过使用mysqlbinlog工具来使恢复数据。
mysql主从复制的原理图

主从原理图.jpg

主：binlog线程——记录下所有改变了数据库数据的语句，放进master上的binlog中；
从：io线程——在使用start slave 之后，负责从master上拉取 binlog 内容，放进 自己的relay log中；
从：sql执行线程——执行relay log中的语句

2.开启binlog日志功能

1）编辑打开mysql配置文件/etc/mys.cnf
vim /etc/my.cnf
在[mysqld] 区块添加
log-bin=mysql-bin 确认是打开状态(mysql-bin 是日志的基本名或前缀名)
注意：每次服务器（数据库）重启，服务器会调用flush logs;，新创建一个binlog日志！
2）重启mysqld服务使配置生效
/etc/init.d/mysqld stop
/etc/init.d/mysqld restart
Stopping mysqld: [ OK ]
Starting mysqld: [ OK ]
3）查看binlog日志是否开启
mysql -uroot -p 进入数据库
mysql> show variables like 'log_%';

binlog开启成功

3.Binlog基本配制

• log_bin = mysql-bin
  此参数表示启用binlog功能，并指定路径名称
• binlog_cache_size
  此参数表示binlog使用的内存大小，可以通过状态变量binlog_cache_use和binlog_cache_disk_use来帮助测试。
• binlog_cache_use：使用二进制日志缓存的事务数量
• binlog_cache_disk_use:使用二进制日志缓存但超过binlog_cache_size值并使用临时文件来保存事务中的语句的事务数量-
• max_binlog_size
  Binlog最大值，最大和默认值是1GB，该设置并不能严格控制Binlog的大小，尤其是Binlog比较靠近最大值而又遇到一个比较大事务时，为了保证事务的完整性，不可能做切换日志的动作，只能将该事务的所有SQL都记录进当前日志，直到事务结束
• expire_logs_days = 7
  binlog过期清理时间
• binlog-do-db
  需要备份的数据库名，如果备份多个数据库，重复设置这个选项即可
• binlog-ignore-db
  不需要备份的数据库名
• binlog_format
  binlog日志格式
  日志有三种格式，分别为statement,mixed,以及row.推荐使用mixed

statement：基于SQL语句的模式，某些语句和函数如UUID, LOAD DATA INFILE等在复制过程可能导致数据不一致甚至出错。
row：基于行的模式，记录的是行的变化，很安全。但是binlog会比其他两种模式大很多，在一些大表中清除大量数据时在binlog中会生成很多条语句，可能导致从库延迟变大。
mixed：混合模式，根据语句来选用是statement还是row模式。
下面是看不懂系列

Statement：每一条会修改数据的sql都会记录在binlog中。
优点：不需要记录每一行的变化，减少了binlog日志量，节约了IO，提高性能。(相比row能节约多少性能 与日志量，这个取决于应用的SQL情况，正常同一条记录修改或者插入row格式所产生的日志量还小于Statement产生的日志量，但是考虑到如果带条件的update操作，以及整表删除，alter表等操作，ROW格式会产生大量日志，因此在考虑是否使用ROW格式日志时应该跟据应用的实际情况，其所产生的日志量会增加多少，以及带来的IO性能问题。)
缺点：由于记录的只是执行语句，为了这些语句能在slave上正确运行，因此还必须记录每条语句在执行的时候的一些相关信息，以保证所有语句能在slave得到和在master端执行时候相同的结果。另外mysql 的复制,像一些特定函数功能，slave可与master上要保持一致会有很多相关问题(如sleep()函数， last_insert_id()，以及user-defined functions(udf)会出现问题).
使用以下函数的语句也无法被复制：
LOAD_FILE()
UUID()
USER()
FOUND_ROWS()
SYSDATE() (除非启动时启用了 --sysdate-is-now 选项)
同时在INSERT ...SELECT 会产生比 RBR 更多的行级锁
2.Row:不记录sql语句上下文相关信息，仅保存哪条记录被修改。
优点： binlog中可以不记录执行的sql语句的上下文相关的信息，仅需要记录那一条记录被修改成什么了。所以rowlevel的日志内容会非常清楚的记录下 每一行数据修改的细节。而且不会出现某些特定情况下的存储过程，或function，以及trigger的调用和触发无法被正确复制的问题
缺点:所有的执行的语句当记录到日志中的时候，都将以每行记录的修改来记录，这样可能会产生大量的日志内容,比 如一条update语句，修改多条记录，则binlog中每一条修改都会有记录，这样造成binlog日志量会很大，特别是当执行alter table之类的语句的时候，由于表结构修改，每条记录都发生改变，那么该表每一条记录都会记录到日志中。
3.Mixedlevel: 是以上两种level的混合使用，一般的语句修改使用statment格式保存binlog，如一些函数，statement无法完成主从复制的操作，则 采用row格式保存binlog,MySQL会根据执行的每一条具体的sql语句来区分对待记录的日志形式，也就是在Statement和Row之间选择 一种.新版本的MySQL中队row level模式也被做了优化，并不是所有的修改都会以row level来记录，像遇到表结构变更的时候就会以statement模式来记录。至于update或者delete等修改数据的语句，还是会记录所有行的 变更。

• sync_binlog
  这个参数直接影响mysql的性能和完整性
• sync_binlog=0
  当事务提交后，Mysql仅仅是将binlog_cache中的数据写入Binlog文件，但不执行fsync之类的磁盘 同步指令通知文件系统将缓存刷新到磁盘，而让Filesystem自行决定什么时候来做同步，这个是性能最好的。
• sync_binlog=n，在进行n次事务提交以后，Mysql将执行一次fsync之类的磁盘同步指令，同志文件系统将Binlog文件缓存刷新到磁盘。
  Mysql中默认的设置是sync_binlog=0，即不作任何强制性的磁盘刷新指令，这时性能是最好的，但风险也是最大的。一旦系统绷Crash，在文件系统缓存中的所有Binlog信息都会丢失

4.常用的binlog日志操作命令

1.查看所有binlog日志列表
MySQL [(none)]> show master logs;
+------------------+-----------+
| Log_name | File_size |
+------------------+-----------+
| mysql-bin.000002 | 9059 |
| mysql-bin.000003 | 120 |
| mysql-bin.000004 | 427 |
| mysql-bin.000005 | 210434 |
+------------------+-----------+
2.查看master状态，即最后(最新)一个binlog日志的编号名称，及其最后一个操作事件pos结束点(Position)值
MySQL [(none)]> show master status;
| mysql-bin.000005 | 210434 |
3.重置(清空)所有binlog日志
MySQL [(none)]> reset master;
4.flush刷新log日志，自此刻开始产生一个新编号的binlog日志文件
MySQL [(none)]> flush logs;

5.查看某个binlog日志内容

首先得知道mysql的数据存放目录
用命令： ps -ef|grep mysql

路径是datadir后面

使用mysqlbinlog自带查看.例如：mysqlbinlog mysql-bin.000004
注: binlog是二进制文件，普通文件查看器cat more vi等都无法打开，必须使用自带的 mysqlbinlog 命令查看h
如果报错mysqlbinlog: unknown variable 'default-character-set=utf8'
原因是mysqlbinlog这个工具无法识别binlog中的配置中的default-character-set=utf8这个指令
用mysqlbinlog --no-defaults mysql-bin.000004 命令打开

截取的一部分

解释：
16：47：13 时间信息
insert into ： SQL 语句
server id 1 ： 数据库主机的服务号；
end_log_pos1 196209： sql结束时的pos节点
thread_id=2283： 线程号
上面这种办法读取出binlog日志的全文内容比较多，不容易分辨查看到pos点信息下面介绍一种更为方便的查询命令：
命令格式：
show binlog events [in 'log_name'] [from pos] [limit [offset,]row_count];
参数解释：
in 'log_name' ：指定要查询的binlog文件名(不指定就是第一个binlog文件)
from pos ：指定从哪个pos起始点开始查起(不指定就是从整个文件首个pos点开始算)
limit [offset,] ：偏移量(不指定就是0)
row_count ：查询总条数(不指定就是所有行)
For example:

\G加上为了输出的格式好看,分成有效事件行的方式

再如：指定查询 mysql-bin.000002这个文件，从pos点:624开始查起，偏移2行（即中间跳过2个），查询10条
mysql> show binlog events in 'mysql-bin.000002' from 624 limit 2,10\G;
注意 这个是进入数据库后执行的操作

5.利用binlog日志恢复mysql数据

广告之后，马上回来，重新纪录在一篇吧。。。。

我最后找到了那个sql语句就偷懒直接复制然后再插入进去就可以了。

终于找到你