mysql 誤刪除ibdata1以後的恢復辦法。本站提示廣大學習愛好者：（mysql 誤刪除ibdata1以後的恢復辦法）文章只能為提供參考，不一定能成為您想要的結果。以下是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等文件能否存在。
