mysql 误删除ibdata1之后如何恢复
mysql 误删除ibdata1之后如何恢复
如果误删除了在线服务器中mysql innodb相关的数据文件ibdata1以及日志文件 ib_logfile*,
应该怎样恢复呢?
这时候应该一身冷汗了吧?
==================================
先抽根烟,冷静一下。
==================================
再观察一下网站,发现一切都很正常,数据的读取与写入操作都完全正常。
这是怎么个情况?
其实,mysqld在运行状态中,会保持这些文件为打开状态,
即使把它们删除了,它们仍旧存在于文件系统中,mysqld仍然可以对其进行读写。
lrwx------ 1 root root 64 Aug 7 23:29 3 -> /var/lib/mysql/ibdata1 (deleted)
lrwx------ 1 root root 64 Aug 7 23:29 8 -> /var/lib/mysql/ib_logfile0 (deleted)
lrwx------ 1 root root 64 Aug 7 23:29 9 -> /var/lib/mysql/ib_logfile1 (deleted)
14101是mysqld的pid(进程ID)
只要mysqld不结束,就可以通过proc文件系统找到这几个被删除的文件(已经被Mark为deleted状态)。
这时候应该松了一口气吧。只要把这几个文件复制回 /var/lib/mysql就行了吗?
事情绝对没有这么简单。
因为,在innodb的buffer pool中,有许多dirty page(就是内存中的数据已经被修改,但是没有写回文件中),
如果直接把文件复制回去,轻则数据丢失,重则ibdata1文件损坏。
备份mysql数据的时候,也不能直接备份这几个文件,是同样的道理。
我们必须保证所有buffer pool中的数据修改都保存到了硬盘文件上面,
为此,首先要停止更多的写入/更新/删除操作,然后等待innodb flush pages to disk.
停止写入的话,可以把网站应用关闭,或者lock tables:
Query OK, 0 ROWS affected (0.37 sec)
这时就要等它flush结束,怎样知道有没有结束呢?观察checkpoint age就可以了。
---
LOG
---
Log SEQUENCE NUMBER 363096003
Log flushed up TO 363096003
LAST checkpoint at 363096003
checkpoint age 就是 Log sequence number的值减去 Last checkpoint at的值,
如果为0,那么表示所有的page都flush到硬盘文件中了。
这时就要等它flush结束,怎样知道有没有结束呢?观察checkpoint age就可以了。
---
LOG
---
Log SEQUENCE NUMBER 363096003
Log flushed up TO 363096003
LAST checkpoint at 363096003
checkpoint age 就是 Log sequence number的值减去 Last checkpoint at的值,
如果为0,那么表示所有的page都flush到硬盘文件中了。
为了加速这个flush的过程,可以这样设置一下:
Query OK, 0 ROWS affected (0.01 sec)
此外,还必须保证一些后台的线程完成了它们的工作,
比如insert buffer thread. ibuf的大小应该=1
INSERT BUFFER AND ADAPTIVE HASH INDEX
-------------------------------------
Ibuf: SIZE 1, free list len 398, seg SIZE 400,
还有purge thread,它应该purge了全部的transactions:
TRANSACTIONS
------------
Trx id counter 0 16644
Purge done FOR trx's n:o < 0 16644 undo n:o < 0 0
还要确保innodb不再进行写操作了:
--------
I/O thread 0 state: waiting FOR i/o request (INSERT buffer thread)
I/O thread 1 state: waiting FOR i/o request (log thread)
I/O thread 2 state: waiting FOR i/o request (READ thread)
I/O thread 3 state: waiting FOR i/o request (WRITE thread)
Pending normal aio reads: 0, aio writes: 0,
ibuf aio reads: 0, log i/o's: 0, sync i/o's: 0
Pending flushes (fsync) log: 0; buffer pool: 0
332 OS file reads, 47 OS file writes, 32 OS fsyncs
0.00 reads/s, 0 avg bytes/READ, 0.00 writes/s, 0.00 fsyncs/s
然后把文件复制回去:
root@localhost:/var/lib/mysql# cp /proc/14101/fd/8 /var/lib/mysql/ib_logfile0
root@localhost:/var/lib/mysql# cp /proc/14101/fd/9 /var/lib/mysql/ib_logfile1
修改权限
root@localhost:/var/lib/mysql# chown -R mysql ib* 重启mysqld
root@localhost:/var/lib/mysql# /etc/init.d/mysql restart
结束~~~
结论:
1) 出现意外时,千万不能慌张,抽根烟先冷静一下。
2) 在解决方案不明确的时候,不要进行操作,比如重启mysqld,重启服务器。
3) 有必要监控mysql的ibdata等文件是否存在。
最新文章
- p2p网贷系统即将上线
- win10打开组策略提示命名空间已经被定义
- Nagios学习笔记四:基于NRPE监控远程Linux主机
- c与c++中的extern const的区别和联系
- 配置windows失败,还原更新,请勿关机
- 学霸网站之NABCD
- chrome开发配置(二)获取源代码
- 第二百三十二天 how can I 坚持
- storm单机版安装配置
- 用python输出汉字字库
- 华为-on练习--身高找到最好的二人
- jquery ajax 发送邮件例子
- MySQL 数据库字符集 utf8 和 utf8mb4 的区别
- 软件工程(GZSD2015) 第二次作业文档模板
- Java获取项目根目录等其他系统属性
- Java中关键字this、super的含义及使用
- excel技巧--多行排成单列
- Mysql基础知识—索引
- Antd前端开发采坑记录
- JQuery------帮助文档
热门文章
- ie8中支持 password 的 placeholder
- Ubuntu下第一个C程序的成功运行
- 使用记事本+CSC编译程序
- iTerm2 颜色配置
- emmet(Zen coding)帮助文档
- [大牛翻译系列]Hadoop(9)MapReduce 性能调优:理解性能瓶颈,诊断map性能瓶颈
- Redis源码研究--redis.h
- php文本操作方法集合比较
- PHP环境搭建(Windows8.1+IIS8.5+PHP5.6+PHPStorm)
- Python开发【第一篇】Python基础之函数递归