最近参与一个产品项目，解决一个技术痛点，对于binlog解析的需求。
本来打算用官方mysqlbinlog来解析，配合我们程序经行格式化梳理，再生成可筛选的sql脚本，实现误删除快速恢复等功能。不过后来卡在格式化梳理这块了，因为没有规律，确实比较难，单纯用mysqlbinlog解析等于就是把命令行 给搞到界面上了，没有任何意义了。
经过一段事件研究，发现了几款开源工具比较适合我们需求，虽然MyFlash解析速度最快，但是仅支持5.7，意义就不大了，综合看下来，binlog2sql这款最适合。这个功能就是实现Oracle里面的flashback，非常具有卖点。
简单介绍下binlog2sql，从MySQL binlog解析出你要的SQL。根据不同选项，你可以得到原始SQL、回滚SQL、去除主键的INSERT SQL等（摘自github资料）
限制（对比mysqlbinlog）
- mysql server必须开启，离线模式下不能解析
- 参数 binlog_row_image 必须为FULL，暂不支持MINIMAL
- 解析速度不如mysqlbinlog
优点（对比mysqlbinlog）
- 纯Python开发，安装与使用都很简单
- 自带flashback、no-primary-key解析模式，无需再装补丁
- flashback模式下，更适合闪回实战
- 解析为标准SQL，方便理解、筛选
- 代码容易改造，可以支持更多个性化解析
注意点：
1 drop truncate无法生成回退sql，日志中显示的只有实际执行语句。
2 执行binlog2sql的时候无需拷贝binlog，直接执行即可
3 多个binlog的话，那就指定一个stop-file，注意stop-file一定要比start-file大，不然的话虽然不报错，但是输出为空
4 恢复的难点，第一个，你要确认好那个点，第二个，对于正在进行的业务来说，无法进行恢复，因为一直在更新，日志在变化，无法确认终止的binlogfile
5 支持MySQL5.6，5.7。 而 8.0暂时没有测试
测试结果
- 本文标题： binlog2sql选型报告
- 文章作者： sherryriver（木木三可）
- 发布时间： 2020.10.29
- 本文链接： https://sherryriver.github.io/2020/10/29/binlog2sql选型报告/
- 许可协议： "署名-非商用-相同方式共享 4.0" 转载请保留原文链接及作者。