新年伊始，各位友友们是否已经调整好状态投入到工作中呢？昨天公司测试服务器上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已经找回来。总算是虚惊一场。
总结：运维这份工作真的是需要慎之又慎，一个不小心就可能造成很大的损失，要做好日常备份，牵扯到数据的操作要再三考量然后才能执行，以免丢失数据悔之不及。切记~