MySQL 誤刪 ibdata1 緊急恢復全流程實戰

事故現場

線上服務器誤執行 rm -f ibdata1 ib_logfile*，但 MySQL 進程仍在運行，業務讀寫看似正常。

核心原理：Linux 文件描述符機制

已刪除但被進程持有的文件，實際數據仍駐留磁碟，可通過 /proc/PID/fd/ 訪問：

ls -la /proc/$(pidof mysqld)/fd/ | grep -E 'ibdata|ib_log'
# 輸出示例:
# lrwx------ 1 mysql mysql 64 Jan 15 10:00 3 -> /var/lib/mysql/ibdata1 (deleted)

恢復關鍵難點：髒頁刷盤一致性

InnoDB Buffer Pool 中的髒頁未刷盤，直接複製文件會導致：

• 數據丟失 (未持久化的變更)
• 表空間損壞 (LSN 不一致)

標準化恢復操作步驟

步驟 1: 凍結寫入並等待刷盤

mysql> FLUSH TABLES WITH READ LOCK;
mysql> SET GLOBAL innodb_max_dirty_pages_pct=0;  -- 強制加速髒頁刷盤

步驟 2: 監控 Checkpoint Age 歸零

mysql> SHOW ENGINE INNODB STATUS\G
# 關鍵指標:
# Log sequence number: 363096003
# Log flushed up to:   363096003
# Last checkpoint at:  363096003
# checkpoint age = LSN - Last checkpoint = 0 表示刷盤完成

步驟 3: 驗證後台線程空閒

# INSERT BUFFER
Ibuf: size 1, free list len ..., seg size ...

# PURGE THREAD
Purge done for trx's n:o < 16644 undo n:o < 0

# FILE I/O 所有線程處於 waiting 狀態，Pending flushes = 0

步驟 4: 從 /proc 恢復文件並重啟

PID=$(pidof mysqld)
cp /proc/$PID/fd/3 /var/lib/mysql/ibdata1
cp /proc/$PID/fd/8 /var/lib/mysql/ib_logfile0
cp /proc/$PID/fd/9 /var/lib/mysql/ib_logfile1
chown mysql:mysql /var/lib/mysql/ib*
systemctl restart mysqld

避坑指南與預防措施

1. 絕不重啟 MySQL 確認恢復方案前，重啟會導致文件描述符釋放，數據永久丟失
2. 部署文件監控: 使用 inotify 或 Auditd 監控 ibdata* 刪除事件
3. 啟用獨立表空間: innodb_file_per_table=ON 降低單點故障影響面
4. 定期邏輯備份: mysqldump 邏輯備份不依賴物理文件完整性

總結

利用 Linux 文件描述符特性搭配 InnoDB 刷盤機制，可在不停機情況下實現物理文件級災難恢復。核心在於「鎖表 → 刷盤驗證 → 文件找回 → 重啟驗證」的標準化流程執行。