删库不跑路，我含泪写下MySQL数据恢复大法- Java学习者

日常工作中，总会有因手抖、写错条件、写错表名、错连生产库造成的误删库表和数据的事情发生，那么，如果连数据都恢复不了，还要什么 DBA。

前言

数据恢复的前提的做好备份，且开启 binlog, 格式为 row。

如果没有备份文件，那么删掉库表后就真的删掉了，lsof 中还有记录的话，有可能恢复一部分文件，但若刚好数据库没有打开这个表文件，那就只能跑路了。

如果没有开启 binlog，那么恢复数据后，从备份时间点开始的数据都没得了。

如果 binlog 格式不为 row，那么在误操作数据后就没有办法做闪回操作，只能老老实实地走备份恢复流程。

直接恢复

直接恢复是使用备份文件做全量恢复，这是最常见的场景。

| mysqldump备份全量恢复

使用 mysqldump 文件恢复数据非常简单，直接解压了执行

gzip -d backup.sql.gz | mysql -u<user> -h<host> -P<port> -p

| xtrabackup备份全量恢复

恢复过程

# 步骤一：解压（如果没有压缩可以忽略这一步）innobackupex --decompress <备份文件所在目录>
# 步骤二：应用日志innobackupex --apply-log <备份文件所在目录> 
# 步骤三：复制备份文件到数据目录innobackupex --datadir=<MySQL数据目录> --copy-back <备份文件所在目录>

| 基于时间点恢复

基于时间点的恢复依赖的是binlog日志，需要从 binlog 中找过从备份点到恢复点的所有日志，然后应用，我们测试一下

新建测试表

chengqm-3306>>show create table mytest.mytest \G;*************************** 1. row ***************************       Table: mytestCreate Table: CREATE TABLE `mytest` (  `id` int(11) NOT NULL AUTO_INCREMENT,  `ctime` datetime DEFAULT NULL,  PRIMARY KEY (`id`)) ENGINE=InnoDB DEFAULT CHARSET=utf8

每秒插入一条数据

[mysql@mysql-test ~]$ while true; do mysql -S /tmp/mysql.sock -e 'insert into mytest.mytest(ctime)values(now())';date;sleep 1;done

备份

[mysql@mysql-test ~]$ mysqldump --opt --single-transaction --master-data=2 --default-character-set=utf8 -S /tmp/mysql.sock -A > backup.sql

找出备份时的日志位置

[mysql@mysql-test ~]$ head -n 25 backup.sql | grep 'CHANGE MASTER TO MASTER_LOG_FILE'-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000032', MASTER_LOG_POS=39654;

假设要恢复到 2019-08-09 11:01:54 这个时间点，我们从 binlog 中查找从 39654 到 019-08-09 11:01:54 的日志

[mysql@mysql-test ~]$ mysqlbinlog --start-position=39654 --stop-datetime='2019-08-09 11:01:54' /data/mysql_log/mysql_test/mysql-bin.000032 > backup_inc.sql[mysql@mysql-test-83 ~]$ tail -n 20 backup_inc.sql