北在南方

每天进步一点点

  • 博客访问: 6848265
  • 博文数量: 1031
  • 用 户 组: 普通用户
  • 注册时间: 2009-10-07 13:14
个人简介

MySQL DBA NoSQL DEVOPS

ITPUB论坛APP

ITPUB论坛APP



APP发帖 享双倍积分

文章分类

全部博文(1031)

微信关注

IT168企业级官微



微信号:IT168qiye



系统架构师大会



微信号:SACC2013

订阅
热词专题

分类: MySQL

一 前言
  本周接二连三的出现开发人员在测试环境和生产误操作导致数据库误删除/更新,对DBA而言,回滚数据着实是一件头疼的事情,凡涉及到恢复线上数据必然对应用带来一定的影响。大多数情况是开发误操作delete数据,update多数行,根据之前的操作经验,本文介绍常用的恢复方法。
  写本文的时候 Monogdb 也被曝出有被利用安全漏洞,数据被删除了,希望各位DBA/安全相关人员及时查看自己负责的业务数据库安全相关问题,保护好自己的数据。
二常用的恢复方式
2.1 利用备份恢复
  使用这种方式的前提必须有最近的备份集或者知道出现误操作起始的binlog 位点或者GTID,利用备份集恢复到中间的机器上,然后利用MySQL的slave 特性
  1. START SLAVE [SQL_THREAD] UNTIL
  2.     MASTER_LOG_FILE = 'log_name', MASTER_LOG_POS = log_pos;
  3. until_option:
  4.     UNTIL { {SQL_BEFORE_GTIDS | SQL_AFTER_GTIDS} = gtid_set
  5.           | MASTER_LOG_FILE = 'log_name', MASTER_LOG_POS = log_pos
  6.           | RELAY_LOG_FILE = 'log_name', RELAY_LOG_POS = log_pos
  7.           | SQL_AFTER_MTS_GAPS }
恢复出到一个临时的实例,将误删除,更新的数据 dump 出来并恢复到老的实例里面。恢复数据期间的受影响的表最好不可写,否则将难以达到最想要的结果。例如
a=2 ,被误更新为 a=4,恢复的期间有被更新为a=7 ,结果恢复后又恢复为a=2 。
此种恢复方式 不适合恢复大量数据库,且需要临时实例。
2.2 利用开源工具binlog2sql 恢复。
  binlog2sql 是大众点评公司的DBA 开发的一款基于通过解析binlog将delete 恢复为insert,update 的值 set 字段和where条件做对调的原理来恢复数据的。
  使用限制 MySQL的binlog format 必须是row 
安装
  1. git clone https://github.com/danfengcao/binlog2sql.git && cd binlog2sql
  2. pip install -r requirments.txt
用法
  1. usage: binlog2sql.py [-h HOST] [-u USER] [-p PASSWORD] [-P PORT]
  2.                      [--start-file STARTFILE] [--start-position STARTPOS]
  3.                      [--stop-file ENDFILE] [--stop-position ENDPOS]
  4.                      [--start-datetime STARTTIME] [--stop-datetime STOPTIME]
  5.                      [--stop-never] [--help] [-d [DATABASES [DATABASES ...]]]
  6.                      [-t [TABLES [TABLES ...]]] [-K] [-B]
例子
  1. create table flashback(
  2. id int(11) not null auto_increment primary key ,
  3. stat int(11) not null default 1
  4. ) engine=innodb default charset=utf8;
  5. insert into flashback(stat) values (2),(3),(4),(7),(9),(22),(42),(33),(66),(88)
误操作
  1. update flashback set stat=15
恢复数据的步骤
1 获取误操作的dml所在的binlog,不过一般开发可不知道具体binlog,他们只知道什么时间误操作了,binlog2sql支持按照时间范围恢复。
  1. mysql> show master logs;
  2. +------------------+-----------+
  3. | Log_name | File_size |
  4. +------------------+-----------+
  5. | mysql-bin.000009 | 177 |
  6. | mysql-bin.000010 | 464 |
  7. | mysql-bin.000011 | 8209 |
  8. +------------------+-----------+
  9. 3 rows in set (0.00 sec)
本例子中binlog为mysql-bin.000011
2 利用binlog2sql 恢复数据,先解析binlog获取 update 语句的起始位点,本例中  start 5087 end 5428
  1. python binlog2sql.py -h127.0.0.1 -P3307 -udba -p'dbadmin' -dyang -tflashback --start-file='mysql-bin.000011'

使用binlog2sql -B 参数得到恢复的sql

将获取到的sql 执行到数据库,假如生产环境中真的发生了问题,一定要和开发沟通并且确认需要恢复的确切记录。
  1. mysql> select * from flashback;
  2. +----+------+
  3. | id | stat |
  4. +----+------+
  5. | 1 | 2 |
  6. | 2 | 3 |
  7. | 3 | 4 |
  8. | 4 | 7 |
  9. | 5 | 9 |
  10. | 6 | 22 |
  11. | 7 | 42 |
  12. | 8 | 33 |
  13. | 9 | 66 |
  14. | 10 | 88 |
  15. +----+------+
  16. 10 rows in set (0.00 sec)
binlog2sql的限制
   mysql server必须开启,离线模式下不能解析
优点(对比mysqlbinlog)
   纯Python开发,安装与使用都很简单
   自带flashback、no-primary-key解析模式,无需再装补丁
   flashback模式下,更适合闪回实战
   解析为标准SQL,方便理解、调试
   代码容易改造,可以支持更多个性化解析
其实MySQL 还提供了一个参数 sql_safe_updates,该参数将禁止 不带where 条件的delete和update语句。具体用法和介绍还请参考MySQL官方介绍 

三 总结
   本文简单介绍了两种恢复误操作数据的方法,其实还有其他的方式 比如 使用 mysqlbinlog 编写脚本来恢复数据 ,利用闪回的patch 或者去哪儿的inception 等等 ,大家可以继续去研究。保护数据安全乃DBA的基本职责,每年都有各种
因为数据被误删除导致的惨案。希望每个DBA 都能守护好自己的生命线。推荐几篇关于数据恢复相关的文章
[1] mysqlbinlog flashback 5.6完全使用手册与原理
[2] 拿走不谢,Flashback for MySQL 5.7
[3] MySQL闪回方案讨论及实现
[4] danfengcao, binlog2sql: Parse MySQL binlog to SQL you want  ---本文介绍的工具 
[5] MySQL下实现闪回的设计思路 (MySQL Flashback Feature) 
阅读(16638) | 评论(1) | 转发(3) |
给主人留下些什么吧!~~

杨奇龙2017-01-10 15:25:58

mchdba:^_^,最近有没有去研究测试过mysql5.7.17的mgr呢?

周末的时候还在思考要不要 随大流研究一把看看呢,公司目前还没有 MySQL MGR 目前的应用场景。以后要研究估计会自己搭建环境测试一把,熟悉一下大致的技术,不至于 “落后”
现在准备研究 MyRocks ,期待下半年能落地 。

回复 | 举报

mchdba2017-01-09 17:34:43

^_^,最近有没有去研究测试过mysql5.7.17的mgr呢?

评论热议
请登录后评论。

登录 注册