MySQL根据离线binlog快速“闪回”的详情介绍
内容导读
互联网集市收集整理的这篇技术教程文章主要介绍了MySQL根据离线binlog快速“闪回”的详情介绍，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含3961字，纯文字阅读大概需要6分钟。
内容图文
昨天突然有个客户说误操作，自己删除了大量数据，CTO直接将我拉到一个讨论组里，说要帮他们恢复数据。他们自己挖的坑，打算让开发那边根据业务日志去恢复，被告知只记录的删除主键这样的信息，物理删除，无能为力。上服务器看了下记录的日志，发现好几台上面都有被误删的记录输出。阿里RDS虽然可以克隆一个恢复到删除时间点前的实例，但这散落的几万个id找起来费力，还有就是几个表之间关联的数据也要恢复，觉得麻烦。
想到 MySQL 的闪回方案。以前看过好几篇相关文章，甚至差点自己用python撸一个来解析binlog，反转得到回滚sql，实在没空，这下要急用了。赶紧找了下网上“现成的方案”。
正文开始
MySQL（含阿里RDS）快速闪回可以说是对数据库误操作的后悔药，flashback功能可以将数据库返回到误操作之前。但是即使oracle数据库也只支持短时间内的闪回。
网上现有开源的MySQL闪回实现，原理都是解析binlog，生成反向sql: (必须为row模式)
对于 delete 操作，生成insert （DELETE_ROWS_EVENT）
对于 update 操作，交换binlog里面值的顺序 （UPDATE_ROWS_EVENT）
对于 insert 操作，反向生成delete （WRITE_ROWS_EVENT）
对于多个event，要逆向生成sql
上面两种实现方式，都是通过 python-mysql-replication 包，模拟出原库的一个从库，然后 show binary logs 来获取binlog，发起同步binlog的请求，再解析EVENT。但是阿里云 RDS 的binlog在同步给从库之后， 很快就被 purge 掉了 。如果要恢复 昨天 的 部分数据 ，两种方案都是拿不到binlog的。也就是闪回的时间有限。
还有一些比较简单的实现，就是解析 binlog 物理文件，实现回滚，如 binlog-rollback.pl ，试过，但是速度太慢。
为了不影响速度，又想使用比较成熟的闪回方案，我们可以这样做：
借助一个自建的 mysqld 实例，将已purge掉的binlog拷贝到该实例的目录下
在自建实例里，提前创建好需要恢复的表（结构），因为工具需要连接上来从
information_schema.columns获取元数据信息拷贝的时候，可以替换掉mysql实例自己的binlog文件名，保持连续
可能要修改
mysql-bin.index，确保文件名还能被mysqld识别到重启mysql实例，
show binary logs看一下是否在列表里面接下来就可以使用上面任何一种工具，模拟从库，指定一个binlog文件，开始时间，结束时间，得到回滚SQL
再根据业务逻辑，筛选出需要的sql
<!--more-->
总之就是借助另外一个mysql，把binlog event传输过来。温馨提示：
两个实例间版本不要跨度太大
注意文件权限
如果原库开启了gtid，这个自建实例也要开启gtid
示例：
python mysqlbinlog_back.py --host="localhost" --username="ecuser" --password="ecuser" --port=3306 \
--schema=dbname --tables="t_xx1,t_xx2,t_xx3" -S "mysql-bin.000019" -E "2017-03-02 13:00:00" -N "2017-03-02 14:09:00" -I -U
===log will also write to .//mysqlbinlog_flashback.log===
parameter={'start_binlog_file': 'mysql-bin.000019', 'stream': None, 'keep_data': True,
'file': {'data_create': None, 'flashback': None, 'data': None}, 'add_schema_name': False, 'start_time': None,
'keep_current_data': False, 'start_to_timestamp': 1488430800,
'mysql_setting': {'passwd': 'ecuser', 'host': 'localhost', 'charset': 'utf8', 'port': 3306, 'user': 'ecuser'},
'table_name': 't_xx1,t_xx2,t_xx3', 'skip_delete': False, 'schema': 'dbname', 'stat': {'flash_sql': {}},
'table_name_array': ['t_xx1', 't_xx2', 't_xx3'],
'one_binlog_file': False, 'output_file_path': './log', 'start_position': 4, 'skip_update': True,
'dump_event': False, 'end_to_timestamp': 1488434940, 'skip_insert': True, 'schema_array': ['dbname']
}
scan 10000 events ....from binlogfile=mysql-bin.000019,timestamp=2017-03-02T11:42:14
scan 20000 events ....from binlogfile=mysql-bin.000019,timestamp=2017-03-02T11:42:29
...提示：
binlog为ROW格式，dml影响的每一行都会记录两个event：Table_map和Row_log。而table_map里面的table_id并不会影响它在哪个实例上应用，这个id可以认为是逻辑上，记录表结构版本的机制 —— 当它在 table_definition_cache 没有找到表定义时，id自增1，分配给要记录到binlog的表。
mysqlbinlog_back.py 使用经验 ：
务必指定库名、表明，开始的binlog文件名，起始时间，结束时间。可以加快scan的速度。
根据恢复的需要，选择 -I, -U, -D，指定回滚哪些类型的操作。
如果只是恢复部分表数据（非完全闪回），做不到关联表的正确恢复。比如需要恢复delete数据，但无法恢复业务里因为delete引起其它表更新的数据，除非完全闪回。
不支持表字段是 enum 类型的，比如 t_xx3 的f_do_type字段。可以把自建实例上的enum定义改成int。
以上就是MySQL根据离线binlog快速“闪回”的详情介绍的详细内容，更多请关注Gxl网其它相关文章！
内容总结
以上是互联网集市为您收集整理的MySQL根据离线binlog快速“闪回”的详情介绍全部内容，希望文章能够帮你解决MySQL根据离线binlog快速“闪回”的详情介绍所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。
内容备注
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。
内容手机端
扫描二维码推送至手机访问。