MySQL误删物理文件的恢复(Linux)

MySQL误删物理文件的恢复(Linux)

2016-06-12 ITPUB技术社区

以前拜读过一位Oracle大大的文章,结果自己在测试环境也遇到了,顺手记下来
Oracle大大的文章链接http://blog.itpub.net/17203031/viewspace-1077770/

本文来自ITPUB技术博客博主wangwenan6。

—————————————————正文—————————————————–
背景:DB的测试环境误删MySQL的日志文件ib_logfile1
环境:MySQL5.6.27
问题原因的分析:手滑了_(:з」∠)_
总体思路:
最重要的是冷静,不要乱搞…
Linux下的文件描述符的介绍,直接摘录Oracle大大的描述

所以最重要的一点:冷静,不要去随便重启数据库,保持当时候的操作现场;

现场还原:测试环境中模拟误删ib_logfile1
1

然后发现数据依然在正常运行,可以插入新的数据

2

结合之前对Linux的文件描述符的介绍,可以确定这个文件还是存在的~
那么动手找一下,先确定MySQL的进程ID:ps -ef | grep mysql
然后在/proc/fd里面找到这个PID对应的文件夹(文件名=pid),看一下里面的内容

3

可以看到文件还在,但是被标记成了deleted,既然文件还在,那就好办了~
赶紧把文件拷贝回去?  No!
由于日志也有buffer(innodb_log_buffer_size),拷回去之前,要确认这些日志都刷新到了磁盘,同时也要确认在拷贝的时候,没有新的事务在操作MySQL数据库;
所以先执行flush tables with readlock;再执行flush logs;
4

然后看一下新生成的几个binlog,旧一点的binlog里面能看到“误删”ib_logfile1之后执行的语句
6

在新生成的binlog里面则什么都没有
7

确认了旧的redo log已经写入到磁盘,也没有新的事务在执行,那么再把“误删”的文件拷贝回去;

8

错误的场景:


假设最初出现问题的时候,关闭了数据库,最终这个log没了,那么在启动MySQL的时候就会有如下的报错
9

或者是内容有问题,(这里偷懒了,忘了在刷buffer前拷贝一个错误的logfile1,姑且就拿logfile0来凑数了,当成一个错误的logfile….._(:з」∠)_…本质上应该是一样的效果)
10

那么把之前处理好以后拷贝出来的logfile拷回去看看,修改文件的所有者和权限,启动MySQL之后,噫!报错了~

12

对比下之前拷贝一个内容有问题的logfile的错误信息(模拟操作:没有把log buffer的数据刷新到磁盘,结果拷贝出来的logfile不对)

13

数据文件和正确处理的logfile的LSN是恰好对应上的;
为什么明明这个ib_logfile明明有问题,mysql还启动了?
看看两次替换日志文件后, mysql输出的信息(上面是没有刷新buffer的logfile,下面是刷新过buff的)

1413

可以看到数据库根据刷新到磁盘的数据文件的为准,截断了这些有问题的logfile,然后重新生成了新的logfile的LSN。
推测:生成新的logfile的LSN之后,数据文件中的标记位也发生了变更,从3117292814变成了3117292824,这也是为什么第二次拷贝正确的logfile进去之后,还是打印出了错误日志;
—————————————————结束—————————————————-
PS:不管是误删了数据文件还是日志文件,切记不要关掉数据库,且恢复的时候一定要确认缓存数据全部刷新到了磁盘~

0 Comments
Leave a Reply