以前拜读过一位Oracle大大的文章，结果自己在测试环境也遇到了，顺手记下来
Oracle大大的文章链接http://blog.itpub.net/17203031/viewspace-1077770/
-------------------------------------------------------------------------------------正文------------------------------------------------------------------------------------
背景：DB的测试环境误删MySQL的日志文件ib_logfile1
环境：MySQL5.6.27
问题原因的分析：手滑了_(:з」∠)_
总体思路：
最重要的是冷静，不要乱搞...
Linux下的文件描述符的介绍，直接摘录Oracle大大的描述
所以最重要的一点：冷静，不要去随便重启数据库，保持当时候的操作现场；
现场还原：测试环境中模拟误删ib_logfile1
然后发现数据依然在正常运行，可以插入新的数据
结合之前对Linux的文件描述符的介绍，可以确定这个文件还是存在的~
那么动手找一下，先确定MySQL的进程ID：ps -ef | grep mysql
然后在/proc/fd里面找到这个PID对应的文件夹（文件名=pid），看一下里面的内容
可以看到文件还在，但是被标记成了deleted，既然文件还在，那就好办了~
赶紧把文件拷贝回去？ No！
由于日志也有buffer（innodb_log_buffer_size），拷回去之前，要确认这些日志都刷新到了磁盘，同时也要确认在拷贝的时候，没有新的事务在操作MySQL数据库；
所以先执行flush tables with readlock;再执行flush logs;
然后看一下新生成的几个binlog，旧一点的binlog里面能看到“误删”ib_logfile1之后执行的语句
在新生成的binlog里面则什么都没有
确认了旧的redo log已经写入到磁盘，也没有新的事务在执行，那么再把“误删”的文件拷贝回去；
错误的场景：
假设最初出现问题的时候，关闭了数据库，最终这个log没了，那么在启动MySQL的时候就会有如下的报错
或者是内容有问题，（这里偷懒了，忘了在刷buffer前拷贝一个错误的logfile1，姑且就拿logfile0来凑数了，当成一个错误的logfile....._(:з」∠)_...本质上应该是一样的效果）
那么把之前处理好以后拷贝出来的logfile拷回去看看，修改文件的所有者和权限，启动MySQL之后，噫！报错了~
对比下之前拷贝一个内容有问题的logfile的错误信息（模拟操作：没有把log buffer的数据刷新到磁盘，结果拷贝出来的logfile不对）
数据文件和正确处理的logfile的LSN是恰好对应上的；
为什么明明这个ib_logfile明明有问题，mysql还启动了？
看看两次替换日志文件后， mysql输出的信息（上面是没有刷新buffer的logfile，下面是刷新过buff的）
可以看到数据库根据刷新到磁盘的数据文件的为准，截断了这些有问题的logfile，然后重新生成了新的logfile的LSN，
推测：生成新的logfile的LSN之后，数据文件中的标记位也发生了变更，从3117292814变成了3117292824，这也是为什么第二次拷贝正确的logfile进去之后，还是打印出了错误日志；
-------------------------------------------------------------------------------------结束------------------------------------------------------------------------------------
PS：不管是误删了数据文件还是日志文件，切记不要关掉数据库，且恢复的时候一定要确认缓存数据全部刷新到了磁盘~
Oracle大大的文章链接http://blog.itpub.net/17203031/viewspace-1077770/
-------------------------------------------------------------------------------------正文------------------------------------------------------------------------------------
背景：DB的测试环境误删MySQL的日志文件ib_logfile1
环境：MySQL5.6.27
问题原因的分析：手滑了_(:з」∠)_
总体思路：
最重要的是冷静，不要乱搞...
Linux下的文件描述符的介绍，直接摘录Oracle大大的描述
所以最重要的一点：冷静，不要去随便重启数据库，保持当时候的操作现场；
现场还原：测试环境中模拟误删ib_logfile1
然后发现数据依然在正常运行，可以插入新的数据
结合之前对Linux的文件描述符的介绍，可以确定这个文件还是存在的~
那么动手找一下，先确定MySQL的进程ID：ps -ef | grep mysql
然后在/proc/fd里面找到这个PID对应的文件夹（文件名=pid），看一下里面的内容
可以看到文件还在，但是被标记成了deleted，既然文件还在，那就好办了~
赶紧把文件拷贝回去？ No！
由于日志也有buffer（innodb_log_buffer_size），拷回去之前，要确认这些日志都刷新到了磁盘，同时也要确认在拷贝的时候，没有新的事务在操作MySQL数据库；
所以先执行flush tables with readlock;再执行flush logs;
然后看一下新生成的几个binlog，旧一点的binlog里面能看到“误删”ib_logfile1之后执行的语句
在新生成的binlog里面则什么都没有
确认了旧的redo log已经写入到磁盘，也没有新的事务在执行，那么再把“误删”的文件拷贝回去；
错误的场景：
假设最初出现问题的时候，关闭了数据库，最终这个log没了，那么在启动MySQL的时候就会有如下的报错
或者是内容有问题，（这里偷懒了，忘了在刷buffer前拷贝一个错误的logfile1，姑且就拿logfile0来凑数了，当成一个错误的logfile....._(:з」∠)_...本质上应该是一样的效果）
那么把之前处理好以后拷贝出来的logfile拷回去看看，修改文件的所有者和权限，启动MySQL之后，噫！报错了~
对比下之前拷贝一个内容有问题的logfile的错误信息（模拟操作：没有把log buffer的数据刷新到磁盘，结果拷贝出来的logfile不对）
数据文件和正确处理的logfile的LSN是恰好对应上的；
为什么明明这个ib_logfile明明有问题，mysql还启动了？
看看两次替换日志文件后， mysql输出的信息（上面是没有刷新buffer的logfile，下面是刷新过buff的）
可以看到数据库根据刷新到磁盘的数据文件的为准，截断了这些有问题的logfile，然后重新生成了新的logfile的LSN，
推测：生成新的logfile的LSN之后，数据文件中的标记位也发生了变更，从3117292814变成了3117292824，这也是为什么第二次拷贝正确的logfile进去之后，还是打印出了错误日志；
-------------------------------------------------------------------------------------结束------------------------------------------------------------------------------------
PS：不管是误删了数据文件还是日志文件，切记不要关掉数据库，且恢复的时候一定要确认缓存数据全部刷新到了磁盘~
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/30074459/viewspace-2124359/ ，如需转载，请注明出处，否则将追究法律责任。
请登录后发表评论
登录
全部评论
