手抖误删数据？innobackupex和mysqlbinlog实现数据恢复

ゝ一纸荒年。 2022-04-08 11:14 226阅读 0赞

**一、恢复思路**  
以innobackupex全备为基础，mysqlbinlog解析增量binlog，实现全备以来的任意时间点增量恢复。大致过程：  
1.innobackupex实现全库数据恢复，在xtrabackup\_binlog\_info文件中找到起始binlog以及对应的position；  
2.根据需要恢复的范围，利用mysqlbinlog抽取binlog，并应用到数据库里；  
3.解析出来的binlog应用完毕后，确认数据是否正确，然后利用mysqldump将需要的特定数据导出，如果需要覆盖正式库的数据，建议不要覆盖导入，在导入前先备份正式库数据，并将表rename，最后再导入恢复的数据。

**二、注意事项**  
1.binlog里记录着历史操作的时间点，可以根据此信息判断binlog内容是否有用，例如

# at 703
    #181213 13:27:53 server id 128  end_log_pos 750 CRC32 0xc89acd78        Table_map: `sam`.`test5` mapped to number 74

2.解析binlog时切勿用–base64-out选项抑制解析内容中的BINLOG代码，这将会忽略row格式的DML binlog，只保留明文记录的DDL。例如以下BINLOG '处看起来像是乱码，其实这正是在应用binlog时需要执行的内容。

#181213 13:27:53 server id 128  end_log_pos 796 CRC32 0x39acfff0        Update_rows: table id 74 flags: STMT_END_F
    
    BINLOG '
    2e0RXBOAAAAALwAAAO4CAAAAAEoAAAAAAAEAA3NhbQAFdGVzdDUAAQMAAXjNmsg=
    2e0RXB+AAAAALgAAABwDAAAAAEoAAAAAAAEAAgAB///+AQAAAP4GAAAA8P+sOQ==
    '/*!*/;

3.如果有多个binlog需要恢复，不要用以下的方式：

mysqlbinlog binlog.000001 | mysql -u root -p 
    mysqlbinlog binlog.000002 | mysql -u root -p

因为这方式是以两个独立的连接会话去执行binlog内容，如果第一个binlog里包含了临时表的操作，而第二个binlog也包含对这个临时表的操作，当第一条命令执行完毕后，该会话也就随之结束，那么临时表里的数据也就被清除，可能会引起第二个binlog对临时表操作的异常。正确的方式应该是下面这样：  
`mysqlbinlog binlog.000001 binlog.000002 | mysql -u root -p`  
或将binlog先集中解析到一个文件中，再统一应用：

mysqlbinlog binlog.000001 > /tmp/binlog_dum.sql
    mysqlbinlog binlog.000002 >> /tmp/binlog_dump.sql
    mysql -u root -p -e "source /tmp/binlog_dump.sql"

一般如果binlog解析内容没异常，dump文件是能正常执行的。某些情况下，binlog解析内容不知为何会出现乱序，导致了报错``ERROR 1609 (HY000): The BINLOG statement of type `Table_map` was not preceded by a format description BINLOG statement.``

4.这种方式对于数据量大的库实在是耗时太久，所以能避免的误操作尽量避免吧，不要到删库跑路的地步。

**三、其他方式**  
处理误操作的工具，还有一个binlog2sql，可以直接生成回滚语句，后面博文再写。