前言

之前正式服務器數據庫掛掉了，被其他同事覆蓋數據庫，導致正在使用的數據庫無法訪問，并且所有配置全部丟失，幸好data數據存儲在其他路徑免受劫難。
在恢復之前，為避免有人往實例里寫入內容，所以在my.cnf/my.ini（Linux=my.cnf，Windows=my.ini）內添加了innodb_force_recovery=4

正文

innodb_force_recovery影響整個innodb存儲引擎的恢復狀況

說明

在未配置屬性innodb_force_recovery時，它默認值是0（表示可執行所有），并且不存在于my.cnf/my.ini內。
innodb_force_recovery的參數值可以為0-6，當其大于0時，可以對表進行select、create、drop操作，但insert、update、delete是不允許的。并且重要的一點是，當設置為大于0后，以下條目是包含狀態：
1. (SRV_FORCE_IGNORE_CORRUPT):忽略檢查到的corrupt頁。
2. (SRV_FORCE_NO_BACKGROUND):阻止主線程的運行，如主線程需要執行full purge操作，會導致crash。
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):不執行前滾的操作。

附加

innodb_purge_threads

該參數用于定義處理innodb的清除操作模式，默認的是定期回收無用數據的操作。在之前的幾個版本中，清除操作是主線程的一部分，這意味著運行時它可能會堵塞其它的數據庫操作。
從MySQL5.5.X版本開始，該操作運行于獨立的線程中,并支持更多的并發數。用戶可通過設置innodb_purge_threads配置參數來選擇清除操作是否使用單獨線程。
默認為0，即不啟用。設置為 1 時表示使用單獨的清除線程。

樓主因為設置過innodb_purge_threads=1，然后又在進行上面操作時更改了innodb_force_recovery=4，之后導致出現無限loop情況。
查詢原因發現，mysql源碼控制了這2個參數的設置，如果同時啟用，則一直掛起在循環內，所以在開啟innodb_force_recovery時，注意將innodb_purge_threads=0.

總結

以上是生活随笔為你收集整理的MySQL错误Got error -1 from storage engine的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。