快捷導(dǎo)航

mysql 誤刪除ibdata1之后的恢復(fù)方法

更新時(shí)間：2013年12月30日 21:09:24 作者：

如果誤刪除了在線服務(wù)器中mysql innodb相關(guān)的數(shù)據(jù)文件ibdata1以及日志文件 ib_logfile*，應(yīng)該怎樣恢復(fù)呢

mysql 誤刪除ibdata1之后如何恢復(fù)

如果誤刪除了在線服務(wù)器中mysql innodb相關(guān)的數(shù)據(jù)文件ibdata1以及日志文件 ib_logfile*，
應(yīng)該怎樣恢復(fù)呢？

這時(shí)候應(yīng)該一身冷汗了吧？
==================================
先抽根煙，冷靜一下。
==================================
再觀察一下網(wǎng)站，發(fā)現(xiàn)一切都很正常，數(shù)據(jù)的讀取與寫入操作都完全正常。
這是怎么個(gè)情況？

其實(shí)，mysqld在運(yùn)行狀態(tài)中，會保持這些文件為打開狀態(tài)，
即使把它們刪除了，它們?nèi)耘f存在于文件系統(tǒng)中，mysqld仍然可以對其進(jìn)行讀寫。

復(fù)制代碼代碼如下:

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(進(jìn)程ID)

只要mysqld不結(jié)束，就可以通過proc文件系統(tǒng)找到這幾個(gè)被刪除的文件(已經(jīng)被Mark為deleted狀態(tài))。

這時(shí)候應(yīng)該松了一口氣吧。只要把這幾個(gè)文件復(fù)制回 /var/lib/mysql就行了嗎？

事情絕對沒有這么簡單。

因?yàn)?，在innodb的buffer pool中，有許多dirty page(就是內(nèi)存中的數(shù)據(jù)已經(jīng)被修改，但是沒有寫回文件中),
如果直接把文件復(fù)制回去，輕則數(shù)據(jù)丟失，重則ibdata1文件損壞。

備份mysql數(shù)據(jù)的時(shí)候，也不能直接備份這幾個(gè)文件，是同樣的道理。

我們必須保證所有buffer pool中的數(shù)據(jù)修改都保存到了硬盤文件上面，
為此，首先要停止更多的寫入/更新/刪除操作，然后等待innodb flush pages to disk.
停止寫入的話，可以把網(wǎng)站應(yīng)用關(guān)閉，或者lock tables:

復(fù)制代碼代碼如下:

mysql> FLUSH TABLES WITH READ LOCK;
Query OK, 0 ROWS affected (0.37 sec) 

這時(shí)就要等它flush結(jié)束，怎樣知道有沒有結(jié)束呢？觀察checkpoint age就可以了。

復(fù)制代碼代碼如下:

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到硬盤文件中了。

這時(shí)就要等它flush結(jié)束，怎樣知道有沒有結(jié)束呢？觀察checkpoint age就可以了。

復(fù)制代碼代碼如下:

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到硬盤文件中了。

為了加速這個(gè)flush的過程，可以這樣設(shè)置一下：

復(fù)制代碼代碼如下:

mysql> SET global innodb_max_dirty_pages_pct=0;
Query OK, 0 ROWS affected (0.01 sec) 

此外，還必須保證一些后臺的線程完成了它們的工作，
比如insert buffer thread. ibuf的大小應(yīng)該=1

復(fù)制代碼代碼如下:

------------------------------------- 
INSERT BUFFER AND ADAPTIVE HASH INDEX 
------------------------------------- 
Ibuf: SIZE 1, free list len 398, seg SIZE 400, 

還有purge thread，它應(yīng)該purge了全部的transactions:

復(fù)制代碼代碼如下:

------------ 
TRANSACTIONS 
------------ 
Trx id counter 0 16644 
Purge done FOR trx's n:o < 0 16644 undo n:o < 0 0

還要確保innodb不再進(jìn)行寫操作了：

復(fù)制代碼代碼如下:

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

然后把文件復(fù)制回去：

復(fù)制代碼代碼如下:

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
修改權(quán)限
root@localhost:/var/lib/mysql# chown -R mysql ib* 重啟mysqld
root@localhost:/var/lib/mysql# /etc/init.d/mysql restart
結(jié)束~~~

結(jié)論：
1) 出現(xiàn)意外時(shí)，千萬不能慌張，抽根煙先冷靜一下。
2) 在解決方案不明確的時(shí)候，不要進(jìn)行操作，比如重啟mysqld，重啟服務(wù)器。
3) 有必要監(jiān)控mysql的ibdata等文件是否存在。

您可能感興趣的文章: