当前 MySQL 业界的几种 flashback 实现
mysqlbinlog 工具配合 sed、awk:先将 binlog 解析成类 SQL 的文本,再使用 sed、awk 把类 SQL 文本转换成真正的 SQL,同时实现语句的翻转。
优点:当 SQL 中字段类型比较简单时,可以快速生成需要的 SQL ,且编程门槛也比较低。
缺点:需要考虑极其复杂的转义等情况,出错概率很大。事实上基本也不会有人这么干的了
直接使用 MariaDB 的 mysqlbinlog 工具,该工具已支持 flashback
优点:「官方」出品;直接使用
缺点:由于部分功能的实现不同(例如JSON字段的实现),容易出现不兼容原生 MySQL 的 binlog 文件的情况:目前已知的是使用 MariaDB 的 mysqlbinlog 工具对原生 MySQL server 产生的 binlog 中带有 json 字段则会解析失败
基于业界开源的 binlog 解析库(python-mysql-replication)进行二次开发,直接实现回滚 SQL 的构造,优秀代表是美团点评团队:binlog2sql
优点:使用现成解析库方便就手,信手拈来,上手难度低
缺点:实现上受制于开源库提供的功能,运行效率低,需要使用开源解析库,将 binlog 解析成文本,再操作文本回滚
自行开发工具对 binlog 文件进行解析与修改:优秀代表同样是美团点评团队在2017年开源的MyFLash
优点:binary 层面的操作,只须关注 binlog 格式与字段类型计算,对于数据库的代码重构不敏感,只要 binlog 版本不变,则不需要大改
缺点:实现上只适配了 v4 版本的 binlog 格式,不能解析 v4 以前的老版本;由于不能复用 binlog 解析代码,需要处理 binlog 中复杂的字段大小关系
给源码打 patch:直接修改源码扩展 mysqlbinlog 工具的功能,增加 Flashback 的选项操作。
优点:复用了server 层中 binlog 解析代码,因此无须关心复杂的字段类型;能够结合使用到 mysqlbinlog 原有的一些过滤选项
缺点:需要对 mysql 的复制代码结构和细节需要有较为清晰深入的理解;改动的代码分布在 MySQL 的各个文件和函数中,MySQL 版本更新有可能需要重新对 patch 进行适配
————————————————
版权声明:本文为CSDN博主「nieops」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。
原文链接:https://blog.csdn.net/weixin_38625669/article/details/91523063