DU MySQL Binlog Restore ，自动解析出已被删除、被破坏的残缺binlog碎片-2020.11.15

使用场景

场景一

binlog文件默认保存7天，因误删数据，需要用7天前的binlog恢复数据

场景二

binlog文件被损坏，mysqlbinlog解析时报错，不能解析出完整的binlog sql

工作原理

• 文件恢复工具，难以恢复被删除、部分覆盖的binlog文件。原因是binlog是动态增长的，在磁盘上碎片化保存，被删后很容易被覆盖导致不完整。
• binlog文件较大，就算被删除，磁盘上仍有大量binlog碎片，解析出这些binlog碎片，仍能挽回很多数据。
• DU MySQL Binlog Restore 支持从磁盘、分区、磁盘镜像文件、残缺的binlog文件中，解析出所有未被覆盖的binlog碎片，并转换为sql语句，同时按sql语句的时间戳，自动排序所有sql，保证用户可以按正确的顺序导入sql。
• 另外，DU MySQL Binlog Restore对数据源是只读方式打开的，以防止破坏原始数据：
  

以下分别演示windows和linux环境下的恢复步骤

Windows服务器恢复示例

1. 下载DU_MySQL_BinLog_Restore.exe
   
2. 运行DU_MySQL_BinLog_Restore.exe

• 如果binlog源为文件（如binlog文件、磁盘镜像、分区镜像等），则可以普通用户运行。
• 如果binlog源为裸磁盘、分区，则必须以管理员身份运行工具。
  注意：勿将DU_MySQL_BinLog_Restore放在数据源分区运行，以免输出文件覆盖原始数据！
  

3. 输入数据源

• 如果数据源是分区，则可直接输入a-z的盘符
• 如果数据源是磁盘，则可直接输入0-9的磁盘序号（请参考磁盘管理器中的盘序）
• 如果数据源是文件，则可直接将文件拖入cmd窗口（注意文件必须保存在英文路径下，且无空格）
  以下示例扫描test文件，显示all binlog event数量后，表示扫描完成：
  

4. 查看扫描结果
   完成后在运行目录创建RESTORE_FILE目录，RESTORE_FILE下生成4个文件：

• sql.tmp----临时乱序sql文件
• sql.map----sql排序缓存
• binlog.sql----已排序的输出sql文件，可导入mysql数据库
• search.log----扫描日志

4. 导入sql数据

• 从完整binlog导出的sql，一般会有建库、建表的语句，可直接导入；
• 从不完整的磁盘中扫描binlog碎片，不一定有建库、建表的语句，这种情况需要管理员判断是否要手动建库、建表，再导入sql数据。
• 另外，DU_MySQL_BinLog_Restore导出的sql都带 USE xxxdb 显式指定数据库，如导入报错，可以用EmEditor / Notepadd+ 等工具批量删除之。

Linux服务器恢复示例

1. 上传 DU_MySQL_BinLog_Restore_Linux 到 Linux 。注意不要上传到mysql data 目录所在的同一分区； 如果 Linux 服务器只有一个分区，且估计 binlog 大小不超过内存容量的50%，则可将工具上传到 /dev/shm 目录。 /dev/shm是内存虚拟目录，写入数据在内存中不落盘，系统重启后/dev/shm 自动清空。
2. 给执行权限

chmod 777 DU_MySQL_BinLog_Restore_Linux

3. 运行工具，扫描mysql data 目录所在的分区。以下示例扫描/dev/sda3，请按实际情况指定源路径！

sudo ./DU_MySQL_BinLog_Restore_Linux -s /dev/sda3

4. 下载binlogfile到windows上
   
5. 运行DU_MySQL_BinLog_Restore.exe解析binlog.sql
   config.ini中配置参数：LINUX_BINLOG=1
   运行DU_MySQL_BinLog_Restore.exe，将binlogfile直接拖入cmd窗口开始解析：
   RESTORE_FILE下解析出binlog.sql:
   

版本差异

下载地址

DU_MySQL_Binlog_Restore_v2.3_2020-11-17.zip

链接：https://pan.baidu.com/s/1AU7c0gsN0uxo1yCaR9NLBQ
提取码：n6sr

最新版本可联系作者QQ 568229095