清理服務器空間遇到的mysql問題

背景：公司生產(chǎn)環(huán)境服務器空間報警，超過80%，緊急檢查發(fā)現(xiàn)是mysql備份服務器，有一個記錄明細的大表，占用空間150G左右。找到了問題，就要解決他。計劃將此表移走，重新建一個空新表，繼續(xù)記錄。在操作過程中因為失誤，導致多饒了好多流程，現(xiàn)在記錄下來。
原計劃：
1、備份這個表，使用xtrabackup
2、對表空間進行硬鏈接（ln命令），目的是不刪除文件本身，而只刪除其指針，從而達到快速刪除，不影響使用，不占用資源的目的。（依賴原理：OS HARD LINK 當多個文件名同時指向同一個INODE時,這個INODE的引用數(shù)N>1, 刪除其中任何一個文件名只是刪除了一個指針而已，不會刪除數(shù)據(jù)文件。當INODE的引用數(shù)N=1時, 刪除文件需要去把這個文件相關的所有數(shù)據(jù)塊清除,所以會比較耗時）。
3、使用drop刪除表，最后刪除表文件。
問題：然而理想很豐滿現(xiàn)實很骨干，打我登陸服務器之后，發(fā)現(xiàn)服務器剩余的空間不足以讓我進行硬鏈接。這就尷尬了，沒辦法，只能另找其他方法。
實際操作：
1、備份完數(shù)據(jù)
2、思索怎么把大表刪除或者移走。最后決定將表空間重命名（mv），然后再操作，但是在mv重命名過程中，因為失誤將ibd文件覆蓋了，導致的問題是此大文件瞬間消失了，但是查看服務器空間發(fā)現(xiàn)其所占空間大小依然存在。按照道理來說，如果mv導致文件覆蓋，文件相當于是被刪除了，空間也應該釋放了，然而沒有?？紤]到文件為mysql表空間文件，可能存在鏈接問題，重啟mysql后，發(fā)現(xiàn)硬盤空間釋放。
3、解決了硬盤空間問題，迎來了新的問題。在原數(shù)據(jù)庫中建立同名表的時候，數(shù)據(jù)庫一直提示表已存在，這就是直接刪除表空間遺留下的問題。因為要新建一個空表，繼續(xù)使用，所以也要解決這個問題。當然如果條件允許的話，可以另見一個結構一樣表名稱不一樣的新表使用。我認為既然遇到了，就解決這個問題。
4、登陸數(shù)據(jù)庫進行drop表測試，發(fā)現(xiàn)提示找不到這張表t1?？紤]到表空間不存在，手動建一個空的表空間。首先是建了一張結構一樣但是表名稱不一樣的表t2，復制t2的表空間并重命名為t1的表空間。重啟數(shù)據(jù)庫，然后再進入數(shù)據(jù)庫，先分離表空間，再drop表，發(fā)現(xiàn)可以成功。然后新建t1表，也可以成功。最后將t2表刪除。
5、此操作雖然沒有問題，但是t1表中原始數(shù)據(jù)會丟失，所以在操作數(shù)據(jù)庫之前一定要備份數(shù)據(jù)。
總結：雖然這是一個不大不小的問題，特別記錄下來，有需要的朋友可以看一下。當然也有一個意外收獲，那就是這樣刪除比drop速度要快得多，而且還不占用資源。