博客列表 >mysql通过binlog二进制日志来恢复数据的方法

mysql通过binlog二进制日志来恢复数据的方法

Coco
Coco原创
2021年12月12日 21:47:23711浏览

  有些萌新做事的时候经常大大咧咧,有一天萌新心血来潮写了个sql delete from tablename 然后小手指一点,糟了没加where条件。萌新的mysql还没入门就到了删库跑路这一步。 数据都没了,怎么办?没关系我们可以使用乾坤大挪移,让时间倒流打死这个萌新。

  一般情况下如果我们有备份的时候,会通过备份来恢复数据库。那么没有备份的时候呢,你最好祈祷开了二进制日志binlog。神马?二进制日志也没开,OK OK 没关系 我们先打死萌新祭数据库,然后以死谢罪。

  话不多说,操作起来。

  一般情况下我们安装mysql之后二进制日志并没有开启,需要我们自行开启。

  开启方法如下:

  1.开启bin-log

  (1)在/etc/myf配置文件里面

  [mysqld] #选项添加

  log-bin=mysql-bin #日志文件名称,未指定位置,默认数据文件位置

  重启mysql服务

  log_bin是生成的bin-log的文件名,后缀则是6位数字的编码,从000001开始,按照上面的配置,生成的文件则为:

  mysql_bin.000001

  mysql_bin.000002

  ......

  基本操作

  2.基本操作

  (1)查看所有日志文件:

  mysql> show binary logs; 或show master logs;

  +------------------+-----------+

  | Log_name | File_size |

  +------------------+-----------+

  | mysql-bin.000001 | 120 |

  +------------------+-----------+

  (2)查看正在写入的日志文件:

  mysql> show master status;

  +------------------+----------+--------------+------------------+-------------------+

  | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |

  +------------------+----------+--------------+------------------+-------------------+

  | mysql-bin.000001 | 120 | | | |

  +------------------+----------+--------------+------------------+-------------------+

  (3)查看当前binlog文件内容:

  mysql> show binlog events; #可以格式化输出 show binlog events\G; 或指定日志文件查看show binlog events in 'mysql-bin.000001';

  +------------------+-----+-------------+-----------+-------------+---------------------------------------+

  | Log_name | Pos | Event_type | Server_id | End_log_pos | Info |

  +------------------+-----+-------------+-----------+-------------+---------------------------------------+

  | mysql-bin.000001 | 4 | Format_desc | 1 | 120 | Server ver: 5.6.25-log, Binlog ver: 4 |

  +------------------+-----+-------------+-----------+-------------+--------------------

  注:

  Log_name:此条log存在哪个文件中

  Pos:log在bin-log中的开始位置

  Event_type:log的类型信息

  Server_id:可以查看配置中的server_id,表示log是哪个服务器产生

  End_log_pos:log在bin-log中的结束位置

  Info:log的一些备注信息,可以直观的看出进行了什么操作

  (4)手动启用新的日志文件,一般备份卖游戏完数据库后执行

  mysql> show master status;

  +------------------+----------+--------------+------------------+-------------------+

  | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |

  +------------------+----------+--------------+------------------+-------------------+

  | mysql-bin.000001 | 120 | | | |

  +------------------+----------+--------------+------------------+-------------------+

  1 row in set (0.00 sec)

  mysql> flush logs; #结束正在写入日志文件

  Query OK, 0 rows affected (0.00 sec)

  mysql> show master status;

  +------------------+----------+--------------+------------------+-------------------+

  | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |

  +------------------+----------+--------------+------------------+-------------------+

  | mysql-bin.000002 | 120 | | | |

  +------------------+----------+--------------+------------------+-------------------+

  (5)删除所有二进制日志,并从新开始记录

  mysql> show master status;

  +------------------+----------+--------------+------------------+-------------------+

  | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |

  +------------------+----------+--------------+------------------+-------------------+

  | mysql-bin.000002 | 120 | | | |

  +------------------+----------+--------------+------------------+-------------------+

  1 row in set (0.00 sec)

  mysql> reset master; #重新开始

  Query OK, 0 rows affected (0.00 sec)

  mysql> show master status;

  +------------------+----------+--------------+------------------+-------------------+

  | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |

  +------------------+----------+--------------+------------------+-------------------+

  | mysql-bin.000001 | 120 | | | |

  +------------------+----------+--------------+------------------+-------------------+

  还有:

  mysql> purge master logs to 'mysql-bin.000002'; #是将'mysql-bin.000002'编号之前的所有日志进行删除

  mysql> purge master logs before 'yyyy-mm-dd hh:mm:ss' #是将在'yyyy-mm-dd hh:mm:ss'时间之前

  3.二进制日志文件导出

  # mysqlbinlog binlog.000001 >1.sql #到处成sql格式

  # mysqlbinlog --start-datetime="2021-03-20 11:25:56" --stop-datetime="2021-03-20 14:20:10" mysql-bin.000001 > /data/test01.log #按时间点导出

  # mysqlbinlog --start-position=203 --stop-position=203 mysql-bin.000001 > /data/test02.log #按事件位置导出

  4.恢复数据

  强烈建议:做任何恢复之前都给数据库做一个完整备份,新建库进行恢复。

  恢复

  bin-log是记录着mysql所有事件的操作,可以通过bin-log做完整恢复,基于时间点的恢复,和基于位置的恢复

  (1)完整恢复,先执行上次完整备份恢复,再执行自上次备份后产生的二进制日志文件恢复

  # mysql localhost mysql-bin.000001 | mysql -uroot -p

  这样数据库就可以完全的恢复到崩溃前的完全状态

  (2)基于时间点的恢复,如果确认误操作时间点为2021-03-20 10:00:00执行如下

  # mysqlbinlog --stop-date='2021-03-02 9:59:59' mysql-bin.000001 | mysql -uroot -p

  然后跳过误操作的时间点,继续执行后面的binlog

  # mysqlbinlog --start-date='2021-03-20 10:01:00' mysql-bin.000001 | mysql -uroot -p

  其中--stop-date='2021-03-20 9:59:59' 和 --start-date='2021-03-20 10:01:00'

  取两时间点

  # mysqlbinlog --start-datetime="2021-03-20 11:25:56" --stop-datetime="2021-03-20 14:20:10" mysql-bin.000001 | mysql -u root -p

  #注:其中的时间是你误操作的时间,而且这个时间点还可能涉及到的不只是误操作,也有可能有正确的操作也被跳过去了。那么执行位置恢复

  基于位置恢复,通过查看日志文件信息,确认6259-6362为误操作点

  # mysqlbinlog --stop-position=6259 mysql-bin.000001 | mysql -uroot -p #从1开始至6259的事件读,不包括6259事件

  # mysqlbinlog --start-position=6363 mysql-bin.000001 | mysql -uroot -p #从6259的事件开始读

  # 取两事件点

  mysqlbinlog --start-position=5786 --stop-position=6254 mysql-bin.000001 | mysql -uroot -p

  到此为止基本就可以恢复被误删的数据了。

  当然我们平时还是要管理好数据库权限,避免萌新们误删数据带来不必要的麻烦。当我们操作生产环境上的正式数据库时候一点要在操作之前先备份,提前做好准备。避免给正式数据库造成不必要的数据污染。

声明:本文内容转载自脚本之家,由网友自发贡献,版权归原作者所有,如您发现涉嫌抄袭侵权,请联系admin@php.cn 核实处理。
全部评论
文明上网理性发言,请遵守新闻评论服务协议