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