标签：pip 变化 primary git clone size only wiki comment 路径
背景：
业务需要恢复一段时间内对某个表的所有DELETE记录，过滤UPDATE、INSERT操作，测试发现 MariaDB的flashback命令会闪回对表的所有dml操作，无法满足业务需求。调研三方工具测试发现binlog2sql可以实现生成原始SQL、回滚SQL、去除主键的INSERT SQL。
binlog2sql介绍：
由大众点评开源的一个 MySQL 闪回工具
用途
- 数据回滚
- 主从切换后数据不一致的修复
- 从 binlog 生成标准 SQL，带来的衍生功能
闪回原理简析
闪回原理，由于 MySQL binlog 以 event 为单位，记录数据库的变更信息，这些信息能够帮助我们重现这之间的所有变化，也就是所谓的闪回。
binlog 有三种可选的格式：
- statement：基于 SQL 语句的模式，binlog 数据量小，但是某些语句和函数在复制过程可能导致数据不一致甚至出错；
- mixed：混合模式，根据语句来选用是 statement 还是 row 模式；
- row：基于行的模式，记录的是行的完整变化。安全，但 binlog 会比其他两种模式大很多；
利用 binlog 做闪回，需要将 binlog 格式设置为 row，因为我们需要最详尽的信息来确定操作之后数据不会出错。
既然 binlog 以 event 形式记录了所有的变更信息，那么我们把需要回滚的 event，从后往前回滚回去即可
回滚操作：
- 对于 delete 操作，我们从 binlog 提取出 delete 信息，反向生成 insert 回滚语句；
- 对于 insert 操作，反向生成 delete 回滚语句；
- 对于 update 操作，根据信息生成反向的 update 语句；
- mysql 服务必须开启，离线模式下不能解析
- 参数 binlog_row_image 必须为FULL，暂不支持MINIMAL
- 解析速度不如mysqlbinlog
- 优点（对比mysqlbinlog）
- 纯Python开发，安装与使用都很简单
- 自带flashback、no-primary-key解析模式，无需再装补丁
- flashback模式下，更适合闪回实战
- 解析为标准SQL，方便理解、筛选
- 代码容易改造，可以支持更多个性化解析
官方测试环境：
Python2.7、3.4+
MySQL5.6、5.7、MariaDB 10.2.11(自测)
安装：
pip install -r requirements.txt
MySQL服务设置
binlog必须开启
binlog格式必须为row格式
binlog_row_image = full 因为需要解析具体行更新前后的变化，所以必须设置为full
连接用户权限：
select, super/replication client, replication slave
建议授权
GRANT SELECT, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO
权限说明
select：需要读取server端information_schema.COLUMNS表，获取表结构的元信息，拼接成可视化的sql语句
super/replication client：两个权限都可以，需要执行‘SHOW MASTER STATUS‘, 获取server端的binlog列表
replication slave：通过BINLOG_DUMP协议获取binlog内容的权限
基本用法：
解析标准SQL：
解析回滚SQL：
连接配置选项
mysql连接配置
-h host; -P port; -u user; -p password
解析模式
--stop-never 持续解析binlog。可选。默认False，同步至执行命令时最新的binlog位置。
-K, --no-primary-key 对INSERT语句去除主键。可选。默认False
-B, --flashback 生成回滚SQL，可解析大文件，不受内存限制。可选。默认False。与stop-never或no-primary-key不能同时添加。
--back-interval -B模式下，每打印一千行回滚SQL，加一句SLEEP多少秒，如不想加SLEEP，请设为0。可选。默认1.0。
解析范围控制
--start-file 起始解析文件，只需文件名，无需全路径 。必须。
--start-position/--start-pos 起始解析位置。可选。默认为start-file的起始位置。
--stop-file/--end-file 终止解析文件。可选。默认为start-file同一个文件。若解析模式为stop-never，此选项失效。
--stop-position/--end-pos 终止解析位置。可选。默认为stop-file的最末位置；若解析模式为stop-never，此选项失效。
--start-datetime 起始解析时间，格式‘%Y-%m-%d %H:%M:%S‘。可选。默认不过滤。
--stop-datetime 终止解析时间，格式‘%Y-%m-%d %H:%M:%S‘。可选。默认不过滤。
对象过滤
-d, --databases 只解析目标db的sql，多个库用空格隔开，如-d db1 db2。可选。默认为空。
-t, --tables 只解析目标table的sql，多张表用空格隔开，如-t tbl1 tbl2。可选。默认为空。
--only-dml 只解析dml，忽略ddl。可选。默认False。
--sql-type 只解析指定类型，支持INSERT, UPDATE, DELETE。多个类型用空格隔开，如--sql-type INSERT DELETE。可选。默认为增删改都解析。用了此参数但没填任何类型，则三者都不解析。
测试
环境：Python2.7.8 MariaDB10.2.11
t1 表T1时刻 原始数据：
t1表T2时刻往后分别删除插入记录：
业务恢复需求：
将数据恢复至T1时刻，但是T1-T2这段时间的INSERT数据不需要恢复，只恢复DELETE的数据（即恢复id=2和3 的记录）
方法1：MariaDB flashback
/usr/local/mariadb/bin/mysqlbinlog --start-datetime=‘2019-06-05 18:49:37‘ -d test -T t1 hf_test-bin.000131 --flashback >recover.sql
可以生成对应的回滚语句，但是包含此表这段时间的所有dml操作，单纯过滤出DELETE操作出错率高，可靠性差
方法2：binlog2sql
解析这段时间对此表的dml操作
生成回滚SQL
过滤文件中业务需要的INSERT语句：
恢复：myin 3308 test <./insert.sql
T1后插入的 dd ,ee 记录保留，删除的bb,cc 恢复完成！
总结：
业务方会根据各种场景提各种奇葩需求，需要DBA根据具体情况具体分析，多测试，才能做到得心应手
MariaDB的flashback很有效，但针对此需求binlog2sql更适合,具体需求具体分析
binlog2sql与MariaDB flashback
标签：pip 变化 primary git clone size only wiki comment 路径
原文地址：https://www.cnblogs.com/DBA-3306/p/10995374.html
