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已经找回来。总算是虚惊一场。

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

MySQL数据恢复一例

上一篇:WebService:asp.net类库中添加WebService引用出现问题解决方法


下一篇:.net core 中 图片转pdf 报错'windows-1252' is not a supported encoding name