mysql 误删除ibdata1之后的恢复方法
mysql 误删除ibdata1之后如何恢复
如果误删除了在线服务器中mysql innodb相关的数据文件ibdata1以及日志文件 ib_logfile*，
应该怎样恢复呢？
这时候应该一身冷汗了吧？
==================================
先抽根烟，冷静一下。
==================================
再观察一下网站，发现一切都很正常，数据的读取与写入操作都完全正常。
这是怎么个情况？
其实，mysqld在运行状态中，会保持这些文件为打开状态，
即使把它们删除了，它们仍旧存在于文件系统中，mysqld仍然可以对其进行读写。
root@localhost:/var/lib/mysql# ls -la /proc/14101/fd/ | grep -e ibdata -e ib_
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:
mysql> FLUSH TABLES WITH READ LOCK;
Query OK, 0 ROWS affected (0.37 sec)
这时就要等它flush结束，怎样知道有没有结束呢？观察checkpoint age就可以了。
mysql> SHOW engine innodb STATUS
---
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就可以了。
mysql> SHOW engine innodb STATUS
---
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的过程，可以这样设置一下：
mysql> SET global innodb_max_dirty_pages_pct=0;
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不再进行写操作了：
FILE I/O
--------
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/3 /var/lib/mysql/ibdata1
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等文件是否存在。
相关文章
ERROR 1045 (28000): Access denied for user ''''root''''@''''
这篇文章主要介绍了Linux下数据库报ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: YES)实用解决方案,希望能对大家有帮助。2017-10-10
这篇文章主要为大家详细介绍了Win中安装mysql的详细步骤，文中安装步骤介绍的非常详细，具有一定的参考价值，感兴趣的小伙伴们可以参考一下2019-10-10
在后端开发中我们不可避免的会遇见MySQL数据并发更新的情况，作为一名后端研发，如何解决这类问题也是必须要知道的，同时这也是面试中经常考察的知识点。2019-05-05
众所周知MySQL 的主键可以是自增的,下面这篇文章主要给大家介绍了关于MySQL8自增主键变化的相关资料,文中通过示例代码介绍的非常详细,需要的朋友可以参考下2022-04-04
很多人在使用Mysql时没有考虑到优化问题，如果遇到上千万数据量的表，查询上千万数据量的时候会发生什么问题，本文就来介绍一下如何快速查询一千万条数据，感兴趣的可以了解一下2021-12-12
这篇文章主要给大家介绍了MySQL服务自动停止的解决方法，文中给出了详细的解决过程，对大家具有一定的参考学习价值，需要的朋友们下面来一起看看吧。2017-06-06
这篇文章主要介绍了MYsql库与表的管理及视图介绍，文章围绕主题展开详细的内容介绍，具有一定的参考价值，需要的小伙伴可以参考一下2022-09-09
这篇文章主要介绍了MySQL去重的方法整理的相关资料,需要的朋友可以参考下2017-07-07
这篇文章主要介绍了MySQL中数据类型相关的优化办法,包括使用多列索引等相关的优化方法,需要的朋友可以参考下2015-07-07
今天小编就为大家分享一篇关于优化InnoDB表BLOB,TEXT列的存储效率，小编觉得内容挺不错的，现在分享给大家，具有很好的参考价值，需要的朋友一起跟随小编来看看吧2019-03-03
最新评论