MySQL工具推荐 | 基于MySQL binlog的flashback工具

1、前言

相信您应该遇到过因为误操作破坏数据库的问题,比如忘了带WHERE条件的UPDATE、DELETE操作,然后就需要进行传统方式的全量 & 增量恢复。现在,给您介绍一下MySQL中的flashback玩法,也可以做到像Oracle的flashback那样。

目前MySQL的 flashback(又称 闪回)一般是利用binlog完成的,能快速完成恢复且无需停机维护。

第一个实现该功能的是阿里云的 彭立勋,他在MySQL 5.5版本上就已实现,并将其开源及提交给MariaDB,为社区提供了非常优秀的参考模型。

2、闪回原理

本节我们先来介绍一下MySQL binlog flashback的基本工作原理。

MySQL的binlog以event的形式,记录了MySQL中所有的变更情况,利用binlog我们就能够重现所记录的所有操作。

MySQL引入binlog主要有两个用途/目的:一是为了主从复制;二是用于备份恢复后需要重新应用部分binlog,从而达到全备+增备的效果。

MySQL的binlog共有三种可选格式(binlog_format),其各有优缺点:

  • statement,基于SQL语句的模式,一般来说生成的binlog尺寸较小,但是某些不确定性SQL语句或函数在复制过程可能导致数据不一致甚至出错;
  • row,基于数据行的模式,记录的是数据行的完整变化。相对更安全,推荐使用(但通常生成的binlog会比其他两种模式大很多);
  • mixed,混合模式,可以根据情况自动选用statement抑或row模式;这个模式下也可能造成主从数据不一直。它属于MySQL 5.1版本时期的过渡方案。因此,如果你现在还使用mixed的话,那你的过渡时间也太久了……

备注:想要使用binlog flashback工具,需要将binlog_format设置为row才行。

3、工具推荐

项目一:mysqlbinlog_flashback

项目作者:赖亿@58到家

github项目地址:https://github.com/58daojia-dba/mysqlbinlog_flashback

也可在github.com上搜索“mysqlbinlog_flashback

项目介绍:产生在线mysqlbinlog的回滚的sql,现在已经在阿里的rds上,db为utf8字符集的生产环境下使用。其他环境没有在生产环境下使用,请小心。

项目使用反馈:laiyi@daojia.com

项目二:binlog2sql 

项目作者:曹单锋

github项目地址:https://github.com/danfengcao/binlog2sql

也可在github.com上搜索“binlog2sql

项目介绍:从MySQL binlog解析出你要的SQL。根据不同选项,你可以得到原始SQL、回滚SQL、去除主键的INSERT SQL等。

项目反馈:danfengcao.info@gmail.com

应用场景

  • flashback,数据快速回滚;
  • 主从切换后数据不一致的修复;
  • 从binlog生成标准SQL,再自行二次开发;

5、使用方法

两个软件的使用上都比简单,都是在 https://github.com/noplay/python-mysql-replication 项目基础上进行的二次开发。

两个项目中都有详细的使用说明,感谢两位作者细心的整理,我们这里不再进行赘述,请自行到作者的项目上查看,如果对你帮助,请记得给个 star 哟!

6、flashback总结

社区里做这块的工具比较多,不开源的这里不在讨论,开源产品随着时间的前进,作者有可能忙于其它事情,没来的及更新也会失效过期。所以使用中需要有一定自我修订能力,也希望各位使用者也能加入到开源的大家庭中,共同维护这些项目。

这两款工具开发时侧重点不同,所以使用中也需要注意一下:

  • mysqlbinlog_flashback 更便重于阿里云 RDS环境的使用。
  • binlog2sql  便重于通常MySQL的处理。从代码上来看,该项目更简洁一点。

在具体使用中及项目定制中那个更合适,只有使用后,找到适合自已就可以。 这也是开源的魅力。 如果对这两个软件有兴趣深度交流的,也可以加到QQ群: 529671799  (两位作者已在)来交流吧。

又搞飞机了,号称有五重备份的GitLab居然也歇了

0、导读

《炉石传说》游戏数据库回档事件刚过去几天,GitLab又来凑热闹了

今天下午开始,朋友圈被GitLab误删数据事件给刷爆了。截止发稿时还是离线维护状态。

中国农历春节前才刚刚出了《炉石传说》游戏数据库回档事件(猜测是因为认为误操作导致数据丢失并且备份也失效)。农历春节都还没过去,GitLab也来给大家增加谈资了。

先来看下官方发布的消息:

不过好在这次误删除的数据不是最关键的代码仓库数据,也算是不幸中的万幸。

GitLab号称有五重备份:

  • 每24小时LVM快照备份;
  • 每24小时常规备份;
  • S3备份;
  • 应该是调用了pg_dump的脚本自动备份;
  • Azure备份(只对 NFS 启用,非数据库备份);

从披露的消息并没看到他们如何确认备份数据的有效性,这也是最可怕的地方:对备份机制过分信任,却可能没有可靠的备份恢复测试及验证机制,这是非常危险的行为。之前我在 今天你检查备份了吗? 这篇文章中强调过:备份文件务必进行恢复测试。此外,重要操作命令一定要想清楚、看清楚了再回车确认,发生事故时再怨天尤人,怪老板没给加薪、没发过年红包、过度加班疲劳等都是扯淡的理由,还是自觉面壁去吧~~

和服务器打交道的都要谨慎,这不仅仅是DBA该具备的素质,也不用搞什么“世界备份日”,最重要的是做好备份、并想进一切手段避免误操作,时刻保持敬畏之心

春节假期马上就要结束了,祝大家在新的一年里搬砖更轻松,最好还是能天天抱金砖,hoho~~