刪除帶有待處理事務的 MySQL 表
有沒有辦法在 MySQL 中刪除帶有待處理事務的 InnoDB 表或數據庫(最好在文件系統級別)?
發生了什麼:
我使用 MySQL 5.5.28 並執行
LOAD DATA INFILE…
將一個巨大的數據集(300M 行)導入到 InnoDB 表中。我以前沒用過set autocommit = 0;
。不幸的是,mysqld
在導入過程中被停止了。當我重新啟動時
mysql
,它會嘗試使用以下消息回滾填充系統日誌的事務:mysqld_safe
$$ 4433 $$:121212 16:58:52 InnoDB:等待 1 個活動事務完成
問題是回滾現在執行了超過 25 個小時,在此期間
mysqld
不接受任何套接字連接。我不能只是刪除
/var/lib/mysql/*
並從頭開始,因為這台機器上還有一些其他 InnoDB 數據庫/表。但是,有問題的表是單獨數據庫中的唯一表。刪除整個表或整個數據庫不是問題,因為之後我可以重新導入所有數據。
您實際上無能為力,因為正在通過ibdata1 內的 UNDO 表空間完成回滾,該表空間應該已經大大增長。
如果您終止 mysqld 程序並重新啟動 mysql,它會在崩潰恢復週期中從上次中斷的地方重新開始。
免責聲明:不對數據失去負責
您可以做的事情可能會導致其他表的數據失去,但是您可以做一些事情來規避 InnoDB 的正常崩潰恢復週期。
有一個名為innodb_force_recovery的啟動選項,它允許您繞過 InnoDB 崩潰恢復的各個階段。
根據MySQL Documentation on Forcing InnoDB Recovery,以下是設置及其效果:
1 (SRV_FORCE_IGNORE_CORRUPT)
讓伺服器執行,即使它檢測到損壞的頁面。嘗試使 SELECT * FROM tbl_name 跳過損壞的索引記錄和頁面,這有助於轉儲表。
2 (SRV_FORCE_NO_BACKGROUND)
阻止主執行緒執行。如果在清除操作期間發生崩潰,此恢復值會阻止它。
3 (SRV_FORCE_NO_TRX_UNDO)
崩潰恢復後不要執行事務回滾。
4 (SRV_FORCE_NO_IBUF_MERGE)
防止插入緩衝區合併操作。如果它們會導致崩潰,請不要這樣做。不計算表統計資訊。
5 (SRV_FORCE_NO_UNDO_LOG_SCAN)
啟動數據庫時不要查看撤消日誌:InnoDB 甚至將不完整的事務視為已送出。
6 (SRV_FORCE_NO_LOG_REDO)
不要執行與恢復相關的重做日誌前滾。
將事務更改隱藏在 UNDO 和 REDO 日誌中,您將面臨以下風險
- 失去本應寫入的數據
- 保留要刪除的數據
如果您預計會有不良副作用,請備份整個 /var/lib/mysql 並將其放在某個位置,以防您想要複製 ibdata1、ib_logfile0 和 ib_logfile1 並重試正常恢復。
如果 mysql 在其中一種模式下完全啟動
- mysqldump 除了有問題的表之外的所有數據
- 關閉mysql
- 刪除 /var/lib/mysql 中的所有內容,除了 /var/lib/mysql/mysql
- 啟動mysql
- 重新載入 mysqldump
警告:確保備份所有內容!
我希望這有幫助 !!!