從 ibdata/frm 文件恢復 mysql
硬碟故障讓我試圖從“數據”文件夾的副本中恢復 mysql 我有“大多數”內容的轉儲但缺少一些數據文件夾有 idbdata1 / 日誌文件 / .frm 文件的文件夾所以，已經閱讀了很多關於這並嘗試了很多事情（見下文）但無法啟動服務 - 我是 mysql 5.5 的 Windows 使用者
- 使用 innodb_force_recovery = 6 的所有原始日誌文件啟動服務
RESULT: InnoDB: Error: log file .\ib_logfile0 is of different size 0 100663296 bytes InnoDB: than specified in the .cnf file 0 178257920 bytes!
- 刪除的日誌文件以 innodb_force_recovery = 6 啟動服務
RESULT: InnoDB: Page directory corruption: infimum not pointed to 131001 19:54:14 InnoDB: Page dump in ascii and hex (16384 bytes):len 16384; hex
- 嘗試在http://www.chriscalender.com/?p=49使用 innodb 恢復說明，但這使用 linux 並且無法在我的 Windows 設置上工作 - 儘管安裝了 perl
我現在卡住了，正要打電話給 Percona - 歡迎任何想法？？？
***編輯
從 3 個月前找到另一個“數據”文件夾 - 可以由此啟動服務，但出現錯誤
Cannot find table xxx from the internal data dictionary of innodb though the .frm table exists etc...對於所有 innodb 表 - 現在正在Google搜尋解決方案
MySQL 伺服器生成和使用的所有文件——ibdata1、ib_logfile*、.frm、.ibd 等，應該可以在作業系統之間互換——我從經驗中知道它們可以在 Solaris 和 Linux 之間互換，但我保持不變我通常可以遠離 Windows，所以我不能肯定地說……但一個選擇可能是讓一個工作的 linux MySQL 5.5 設置開始，然後停止它並將所有這些文件複製到 linux機器代替現有的“數據目錄”。
但是下一個適當的步驟也將高度依賴於到底發生了什麼……伺服器是優雅地終止，還是反复崩潰？而且，這將取決於導致問題的文件。如果它只是一個表中的 .ibd 文件，那麼將該文件重命名為 .ibd 以外的其他文件應該允許 MySQL 跳過該文件並轉到下一個文件。
如果您不使用，
innodb_file_per_table那麼您所有的雞蛋都在一個非常脆弱的籃子裡，ibdata1。如果您啟用了二進制日誌記錄並且只有一個稍微陳舊的備份，那麼還有可能在另一台機器上恢復備份並向前播放二進制日誌以恢復其他數據。
根據您的系統管理專業知識的一般水平、缺乏備份的可用性以及數據的緊迫性和價值，呼叫 Percona 或 SkySQL 可能是最好的計劃。