問題

我寫錯了腳本，ibd 文件被刪除了，該往哪個方向逃跑？

實驗

先來建一個測試庫：

我們在這里開啟了 innodb_file_per_table，但這個參數(shù)并非本實驗所必須，只是為了演示方便。

然后模擬一個業(yè)務(wù)壓力：

現(xiàn)在刪掉相關(guān)的表文件：

可以打開地圖 app，選擇一個方向開始跑路了...

然而我們還可以掙扎一下，

查看一下 MySQL 占用的句柄：

找到被刪除的表：

可以看到，除了臨時表，被我們手工刪除的表也在其中，對應(yīng)文件句柄號 54。

現(xiàn)在我們把數(shù)據(jù)庫的流量鎖起來(如果使用了支持 offline_mode 的版本，可以設(shè)置 offline_mode)：

現(xiàn)在記錄一下表的記錄數(shù)和校驗值，以便跟恢復(fù)后的數(shù)據(jù)比較：

現(xiàn)在通過文件句柄找到消失的數(shù)據(jù)文件，并將其復(fù)制出來(此處注意磁盤空間)：

現(xiàn)在可以將數(shù)據(jù)庫停下來，把恢復(fù)的數(shù)據(jù)復(fù)制到數(shù)據(jù)目錄中，啟動數(shù)據(jù)庫：

看看數(shù)據(jù)是否正常：

看起來還不錯。

實驗原理

Linux 刪除文件其實是減少了對文件的使用數(shù)，當(dāng)使用數(shù)降為 0 時，才正式刪除文件。

所以當(dāng)我們執(zhí)行 rm 時，由于 ibd 文件還在被 MySQL 使用，文件其實并沒有被真實刪除，只是沒辦法通過文件系統(tǒng)訪問。

通過 procfs 查找文件句柄，可以讓我們追蹤到消失的文件。

思考題

即使我們停止了外部的數(shù)據(jù)壓力，MySQL 也會自主做一些 buffer pool 的刷盤操作。

如果在我們復(fù)制數(shù)據(jù)文件的過程中，MySQL 觸發(fā)了 buffer pool 的刷盤操作，那我們獲得的數(shù)據(jù)文件不就不一致了么？是否會造成數(shù)據(jù)錯誤。

---

關(guān)于 MySQL 的技術(shù)內(nèi)容，你們還有什么想知道的嗎？趕緊留言告訴小編吧！

總結(jié)

以上是生活随笔為你收集整理的c语言删除文件中的数据_第20问：删除了数据文件，该往哪个方向逃跑的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。