MySQL 数据恢复利器：my2sql 实战解析与应用场景

1. my2sql 是什么为什么你需要它如果你负责过MySQL数据库运维肯定遇到过这样的场景开发同事不小心执行了DELETE FROM users WHERE id1然后慌慌张张跑过来问你能不能恢复数据。这时候如果只有全量备份binlog的传统恢复方式可能需要几个小时才能搞定。而my2sql可以在几分钟内生成回滚SQL把误删的数据找回来。my2sql是一个用Go语言编写的高性能binlog解析工具它最大的特点就是快。实测解析1GB的binlog文件只需要2-3分钟比Python写的binlog2sql快20倍以上。除了速度快它还支持JSON、BLOB这些复杂数据类型的解析这是很多同类工具做不到的。我去年在处理一个线上事故时就深有体会。当时有个批量更新脚本出错把用户表的积分字段全部清零了。用my2sql定位到问题binlog位置后只用了5分钟就生成了回滚SQL避免了用户投诉。如果是用传统方式至少要停机半小时。2. 手把手教你安装和使用2.1 三种安装方式任你选最简单的就是直接下载预编译的二进制文件wget https://github.com/liuhr/my2sql/releases/download/v0.9.1/my2sql_0.9.1_linux_amd64.tar.gz tar -zxvf my2sql_0.9.1_linux_amd64.tar.gz如果你习惯用Docker官方也提供了镜像docker pull liuhuarong/my2sql对于喜欢折腾的开发者可以从源码编译git clone https://github.com/liuhr/my2sql.git cd my2sql go build -o my2sql注意MySQL账号需要具备REPLICATION SLAVE和REPLICATION CLIENT权限建议专门创建一个只读账号用于binlog解析。2.2 你必须知道的6个核心参数第一次使用时可能会被几十个参数吓到其实日常操作主要用这几个-work-type这是最重要的参数支持三种模式2sql生成原始SQL用于审计或数据迁移rollback生成回滚SQL用于数据恢复stats生成DML统计信息分析大事务-start-file/-start-pos指定从哪个binlog文件开始解析精确到字节位置-stop-file/-stop-pos解析到哪个位置结束-databases/-tables按库名或表名过滤避免解析不相关的数据-output-dir生成的SQL文件保存目录-threads并发线程数默认4物理机可以调到8-163. 真实案例5分钟恢复误删数据3.1 场景还原假设下午3点开发同学误执行了DELETE FROM order_detail WHERE create_time 2024-06-01;这张表有200万条数据误删了最近3个月的50万条订单明细。3.2 具体恢复步骤第一步锁定事故时间范围mysqlbinlog --base64-outputdecode-rows -v mysql-bin.000123 | grep -B 20 DELETE FROM order_detail找到类似这样的输出# at 763215 #240701 15:00:12 server id 1 end_log_pos 763346 CRC32 0x3a1b2c8d Query thread_id113 exec_time0 error_code0 use ecommerce/*!*/; DELETE FROM order_detail WHERE create_time 2024-06-01第二步生成回滚SQL./my2sql -user recover -password xxxx -host 10.0.0.1 -port 3306 \ -work-type rollback \ -start-file mysql-bin.000123 \ -start-pos 763215 \ -stop-pos 763346 \ -databases ecommerce \ -tables order_detail \ -output-dir ./rollback_sql第三步执行恢复source /data/rollback_sql/rollback.123.sql;整个过程在我的测试环境只用了3分28秒平均每秒处理2400条记录的逆向SQL生成。4. 进阶应用主从数据一致性修复4.1 主从切换后的数据同步问题上周我们遇到一个典型场景主库磁盘故障导致HA自动切换但新主库缺失了故障前10分钟的数据。这时候传统的做法是用备份重建从库但有了my2sql可以更优雅地解决。4.2 具体操作流程在老主库服务器找到最后的binlogls -l /var/lib/mysql/mysql-bin.00*解析最后10分钟的DML操作./my2sql -user recov -password xxxx -host 10.0.0.2 -port 3306 \ -work-type 2sql \ -start-file mysql-bin.000456 \ -start-datetime 2024-07-15 14:50:00 \ -stop-datetime 2024-07-15 15:00:00 \ -output-dir ./last_dml在新主库执行生成的SQLmysql -h 10.0.0.1 -u root -p /data/last_dml/all_sql.sql这种方法比全量同步快得多特别是对于大表。我们有个200GB的用户表用传统方式同步要2小时而用my2sql只花了18分钟就补全了差异数据。5. 性能对比为什么选择my2sql5.1 实测数据说话我用相同的1.5GB binlog文件测试了几款主流工具工具名称语言解析时间内存占用功能完整性my2sqlGo2m45s480MB★★★★★binlog2sqlPython58m12s1.2GB★★★☆☆MyFlashC22m33s650MB★★☆☆☆my2sql的并发解析架构让它优势明显。它会把binlog分成多个chunk每个chunk用独立goroutine处理最后合并结果。这种设计特别适合现代多核CPU。5.2 独特的功能亮点大事务分析用-work-type stats可以找出哪些事务影响了大量数据./my2sql -work-type stats -start-file mysql-bin.000123输出示例------------------------------------- | table_name | insert | update | delete | ------------------------------------- | user_logs | 0 | 0 | 384291 | -------------------------------------DDL变更追踪虽然不能回滚DDL但可以记录所有表结构变更GTID支持完美兼容基于GTID的复制环境6. 避坑指南我踩过的那些坑第一次使用时我遇到了一个诡异的问题生成的回滚SQL执行后数据还是不对。后来发现是因为MySQL 8.0默认使用了caching_sha2_password认证插件而my2sql当时还不支持。解决办法是在my.cnf添加[mysqld] default_authentication_pluginmysql_native_password另一个常见问题是时区设置。如果MySQL服务器和应用的时区不一致用-start-datetime参数时要注意时区转换。建议始终使用UTC时间操作-start-datetime 2024-07-01 07:00:00 -time-zone 08:00对于TEXT/BLOB字段如果内容特别大比如超过1MB建议先在小环境测试解析结果。我曾经遇到过解析emoji表情丢失的情况后来发现是字符集设置问题需要在命令中添加-charset utf8mb4