MySQL 1067 錯誤機房斷電後恢復：刪除 ibdata1/ib_logfile 重建並導入備份 (含圖文步驟)

機房斷電導致 MySQL 1067 無法啟動：標準災難恢復流程

非預期斷電造成 InnoDB 系統表空間 (ibdata1) 與重做日誌 (ib_logfile0/1) 損壞，服務報 1067 進程終止。若有可用 mysqldump 邏輯備份，按下列流程可在數分鐘內恢復服務 (資料以備份時間點為準)。

災難恢復步驟 (含關鍵截圖對應操作)

1. 確認錯誤：net start mysql → 1067 錯誤彈窗 (對應截圖 1)。
2. 停止服務：確保 mysqld 進程已完全停止。
3. 備份原資料目錄 (關鍵保護動作)：
   rename C:\mysql\data C:\mysql\data_bak_20240115 (對應截圖 2：刪除用戶資料庫檔案與 ib_logfile*)。
   建議移動而非直接刪除，保留最後防線。
4. 刪除 InnoDB 核心檔案 (在原 datadir)：
   del ibdata1 ib_logfile0 ib_logfile1 (對應截圖 3：刪除 ibdata1)。
5. 啟動服務：MySQL 自動初始化全新系統表空間 (對應截圖 4：服務啟動成功)。
6. 導入邏輯備份：
   mysql -uroot -p < backup_20240114.sql (對應截圖 5：導入中)。
7. 驗證資料：SHOW TABLES; SELECT COUNT(*) FROM key_table; (對應截圖 6：資料正常)。

關鍵風險提示

• 資料遺失：斷電後到最近一次備份之間的寫入將永久遺失。
• 系統表重置：mysql.user、mysql.db 等權限表會重置為初始狀態，需從備份恢復或重建帳號。
• MyISAM 表不受影響：僅 InnoDB 系統表空間重建，MyISAM 表檔案 (.MYD/.MYI) 保留，但需檢查是否需 REPAIR TABLE。

預防同類事故的架構建議

替代嘗試：innodb_force_recovery 導出資料

若無備份或需嘗試搶救近期資料，可在 my.cnf 加入：

[mysqld]
innodb_force_recovery = 1  # 從 1 嘗試到 4，4 以上極高風險

啟動後嘗試 mysqldump 導出核心表，成功則按上述流程重建再導入。嚴禁在 force_recovery > 0 時寫入資料。