記一次 MySQL 數據庫單表恢復事故處理

公司 web 服務架設在阿里雲全家桶上，數據庫用的也是 RDS

昨晚 10 點，運營同事在社區發文章，提示建立失敗，查看接口項目的日誌，是 detail 字段的類型爲 text，多是不夠，須要加長，我選擇了 mediumtext 類型。

數據類型	長度
TINYTEXT	256 bytes
TEXT	65,535 bytes~64kb
MEDIUMTEXT	16,777,215 bytes~16M
BLONGTEXT	4,294,967,295 bytes~4GB

而後執行一個 DDL 語句，以下：

ALTER TABLE `databasename`.`tablename` CHANGE COLUMN `question_detail` `question_detail` mediumint  DEFAULT NULL COMMENT '內容';

執行完了，好的，告訴運營同事，看下能夠發文章了麼？

仍是不行，哦，DDL 寫錯了，應該是【mediumtext】，這裏錯了，把正確的 DDL 語句執行一遍，再問下運營同事

ALTER TABLE `databasename`.`tablename` CHANGE COLUMN `question_detail` `question_detail` mediumtext  DEFAULT NULL COMMENT '內容';

基於一個好的習慣，我再去社區確認下，運營同事的新帖子內容挺不錯，在隨便點點別的帖子。

嗯？我湊？？？社區所有帖子的內容變成 0 了，以下

懵逼了，生產事故吖，看看咋回事，一個想法閃過，sql 有問題，我用 navicat 生成的 sql 語句，更新後的數據類型應該是【mediumtext】，結果我敲到 med 的時候，他就主動補全了【mediumint】，沒有看清，就放到生產執行了，一會兒把全部 detail 的內容，強制轉換成了數字？？

黑人問號臉.jpg

ok，開始想辦法恢復數據，中間各類想辦法，最後依靠阿里雲提供的數據備份管理功能，和本人一瞬間暴漲的工做效率和好運氣，在今天凌晨 1 點搞定了。

至此，我獲得了這個表原本的數據了，好在備份時間和發成事故的時間很相近，又是過年期間發帖頻率很低，查一下表內行數，好的，備份庫的貼子表只差一個生產庫一行，應該就是運營那一篇了，哈哈哈。

執行一個兜底命令，重命名帖子表，先不要刪掉這個表，避免一錯再錯

RENAME TABLE  aws_question to aws_question_bak;

而後把導出來的.sql 文件上傳到能夠鏈接生產庫的服務器，而後把這個.sql 執行下，導入到生產庫裏

$ mysql -h hostname -u username -p < restore.sql 
Enter password:   #輸入root用戶的密碼。

再回來看看貼子，好的，數據恢復了。

回過頭來，咱們在執行一遍更新字段數據類型的 sql

ALTER TABLE `databasename`.`tablename` CHANGE COLUMN `question_detail` `question_detail` mediumtext  DEFAULT NULL COMMENT '內容';

把運營同事新寫的文章，從 bak 表拿出來，導入到本表中，至此，數據徹底存進去了。

😁Happyending😁