前言
1、該方法只介紹了如何救回這個表名(數(shù)據(jù)不恢復(fù)) 如果想要恢復(fù)原來數(shù)據(jù) 直接用extundelete把文件恢復(fù)后放回去即可
2、并且是適用于平時沒有全備的情況下 如果有全備 直接那全備的frm和idb文件放回去 就可以了
3、該方法同樣適用于數(shù)據(jù)表遷移(只遷移一個表) 因?yàn)閐iscard再import的速度 遠(yuǎn)比先dump再恢復(fù)的速度要快得多
建議: 平時備份一下表結(jié)構(gòu)是非常重要的
-- 如果你直接刪除了mysql的表文件 (.frm .idb) 在mysql5.6 可能你就悲劇了 可能再也用不回這個表名了
例子如下
-- 全在datadir目錄下操作
-- 直接刪除了表 tracking20160501的物理文件
| rm -rf tracking20160501.* -- 刪除了表tracking20160501的frm文件和idb文件 |
-- 此時在數(shù)據(jù)庫已經(jīng)看不到該表
| mysql> show tables; -- 查看數(shù)據(jù)庫表 |
-- 但若想再創(chuàng)建該表或刪除該表 也許就悲劇了
| mysql> create table tracking20160501(id int);ERROR 1050 (42S01): Table 'tracking20160501' already exists -- 明明已經(jīng)看不到該表了 卻顯示表已存在mysql> drop table tracking20160501;ERROR 1051 (42S02): Unknown table 'kdnet_analyze.tracking20160501' -- 悲劇了吧 創(chuàng)建不到也刪不到。。 |
-- 查看一下現(xiàn)在的物理文件情況
| ls tracking20160501.*tracking20160501.ibd -- 之前刪除了的表空間文件 他自己又創(chuàng)建了個出來 可能是剛剛的create table命令導(dǎo)致的 這里不用理 |
原因: 由于直接刪除了表的物理文件 但mysql的信息庫 information_schema 或 mysql 庫對該表的信息還存在(具體記在哪里 還沒找出來) 導(dǎo)致mysql還認(rèn)為該表存在 所以創(chuàng)建不了 刪除表時由于又找不到對應(yīng)的物理文件 所以也刪除不了 這樣！！ 難道這個表名就無法再用了嗎？
有解決方法 如下
-- 找其他表(最好是表結(jié)構(gòu)一樣的) 這里找的表叫ip_taobao 先復(fù)制這個表的.frm(表結(jié)構(gòu))文件 改名為誤刪的表名
| cp -a ip_taobao.frm tracking20160501.frm -- 這里為了保持mysql文件的擁有人和所屬組 所以使用-a參數(shù) |
-- 如果下面的操作有什么奇葩問題 可以重啟一下數(shù)據(jù)庫
-- 在mysql里 使用discard space命令 廢棄誤刪表的表空間文件
| alter table tracking20160501 discard tablespace; |
-- 再復(fù)制ip_taobao表的表空間文件 改名為誤刪的表名
| cp -a ip_taobao.ibd tracking20160501.ibd -- 同樣使用-a 保持擁有人和所屬組 |
