MySQL数据恢复一例

新年伊始，各位友友们是否已经调整好状态投入到工作中呢？昨天公司测试服务器上MySQL发生事故，供mantis使用的库因误操作被覆盖掉，幸好使用N久前的完全备份及binlog日志恢复了。

恢复过程及命令记录如下：

1、首先当然是恢复事故发生前的最近备份

# /usr/local/mysql/bin/mysqldump -uroot -p --all-databases < /mysql.sql

其中--all-databases匹配所有库，也可以指定某个库或者表，如何使用看具体情况。mysql.sql是我的备份文件，存放在根目录下。

2、完全备份已经恢复，但还不够，这个完全备份是一个月前的，近一个月的数据依然没有。这部分数据要使用binlog日志进行恢复（幸好还有binlog日志）。

查看一下binlog日志

# ll …… -rw-rw----. 1 mysql mysql        264 1月  14 00:58 mysql-bin.000001 -rw-rw----. 1 mysql mysql        126 1月  14 01:04 mysql-bin.000002 -rw-rw----. 1 mysql mysql        107 1月  14 01:04 mysql-bin.000003 -rw-rw----. 1 mysql mysql        107 1月  14 01:21 mysql-bin.000004 -rw-rw----  1 mysql mysql        126 1月  14 01:58 mysql-bin.000005 -rw-rw----  1 mysql mysql  721170980 1月  14 02:45 mysql-bin.000006 -rw-rw----  1 mysql mysql    2915415 1月  22 20:58 mysql-bin.000007 -rw-rw----  1 mysql mysql   14988076 1月  28 01:59 mysql-bin.000008 -rw-rw----  1 mysql mysql     551013 2月  11 02:19 mysql-bin.000009 -rw-rw----  1 mysql mysql  741190125 2月  11 18:47 mysql-bin.000010 …… -rw-rw----. 1 mysql mysql        399 2月  12 16:34 mysql-bin.index ……

可以看到mysql-bin.000001的时间在mysql.sql的完全备份之后，事故发生的时间在mysql-bin.000009之后（如果要精确的定位事故可以查看binlog日志通过字符偏移量来恢复，我这里没有这种需求，只要一个大概的时间点就ok了）。

3、运行binlog日志进行恢复

# /usr/local/mysql/bin/mysqlbinlog \ > --stop-datetime="2014-02-11 02:19:00" \ > /usr/local/mysql/data/mysql-bin.000001 \ > | /usr/local/mysql/bin/mysql -uroot -p****** …… # /usr/local/mysql/bin/mysqlbinlog \ > --stop-datetime="2014-02-11 02:19:00" \ > /usr/local/mysql/data/mysql-bin.000009 \ > | /usr/local/mysql/bin/mysql -uroot -p******

将mysql-bin.000001到mysql-bin.000009这9个binlog日志全部运行一遍，记得加上用户名、密码。

好了，去查看供mantis使用的那个库，数据已经发生了变化，通知测试部门的同事登陆mantis账号查看，反馈说bug已经找回来。总算是虚惊一场。

总结：运维这份工作真的是需要慎之又慎，一个不小心就可能造成很大的损失，要做好日常备份，牵扯到数据的操作要再三考量然后才能执行，以免丢失数据悔之不及。切记~