不小心drop掉資料庫怎麼辦

不小心drop掉資料庫怎麼半.md

不小心刪掉了mysql資料庫怎麼辦

前情提要

  • 不小心把資料庫給drop掉了、把table刪掉了。
    我的情況是把database整個drop掉、沒有開bin_log紀錄。
  • 因為資料庫版本是5.6，預設innodb_file_per_table=off，因此資料在被drop掉後，紀錄仍然會在ibdata1裡面。

當下處置和準備

1. 趕緊將資料庫服務整個關掉，要記得把所有mysql的process砍掉。

sudo service stop mysqld
  • P.S.最好再用ps aux |grep "mysql" 檢查一下

2. 把mysql資料夾內的ibdata1檔案抓出來。

3. 準備一下原本create 要恢復的 table的sql

我因為是使用django，所以能夠用migrate重現原本的table
因此，只要在使用show create table tableName; 就可以拿到create的sql了

P.S. 如果沒有辦法重現的話，twinDB的恢復工具，裡面有sys_parser工具，可以用ibdata1的資料來產生

4. clone 恢復工具

git clone git@github.com:twindb/undrop-for-innodb.git

5. 產生恢復工具(需要gcc、bison、flex、make)

在clone下來的資料夾內編工具

make

P.S. 假如需要sys_parser工具的話，需要再額外去編這個工具(需要對應的mysql dev package，可以用yum provides "*/mysql_config"，來show出可以下載的dev package)

編譯指令

gcc `mysql_config --cflags` `mysql_config --libs` -o sys_parser sys_parser.c

mysql_config 是mysql的設定檔(通常就叫做mysql_config)。

開始修復

接下來的動作，都是在clone下來的工具的資料夾下操作

手動查的流程

1. 使用stream_parser把ibdata1導成page

./stream_parser -f ibdata1檔案

2. 使用c_parser來parse第1個page(可以在這分析出table id)，並找到對應的database/table

EX: 要找django_database下的user table

./c_parser -4Df pages-ibdata1/FIL_PAGE_INDEX/0000000000000001.page -t dictionary/SYS_TABLES.sql |grep "django_database/user"

會得到類似這樣的結果，其中，在table名稱後面的，就是他的table Id
000000000521 3B00000149047E SYS_TABLES "django_database/user" 152 3 33 0 64 "" 0 SET FOREIGN_KEY_CHECKS=0;

3. 使用c_parser來parse第三個page(可以在這分析出index id)

EX: 要找的table id 是 152

./c_parser -4Df pages-ibdata1/FIL_PAGE_INDEX/0000000000000003.page -t dictionary/SYS_INDEXES.sql | grep '152'

會得到類似這樣的結果，接在table id後面的，就是這個key的index id了
000000000521 3B0000014903A2 SYS_INDEXES 153 45 "PRIMARY" 1 3 0 4294967295 SET FOREIGN_KEY_CHECKS=0;
000000000521 3B0000014903A2 SYS_INDEXES 152 49 "Foreign" 1 3 0 4294967295
這邊選擇Primary key id 45

其實剛剛編好的工具裡面，可以產生相對應的查詢表

1. 把recover_dictionary.sh 裡面的43、50、58行的mysql改成自己mysql登入的指令 例如: mysql -u root -p"密碼"

2. 執行recover_dictionary.sh

./recover_dictionary.sh

這樣就會在這台mysql裡面建立一個database 叫test

3. 就可以直接在這個database裡面下sql來查對應的index id了。

#查詢 table id
select * from SYS_TABLES where name like 'django_database/user%';

#查詢 index id
select * from SYS_INDEXES where table_id=152;

可以很輕鬆的查到對應的index id。

接著真的要開始修復了

1. 先查一下對應index_id的page名稱

ls pages-ibdata1/FIL_PAGE_INDEX/*剛剛查到的index_id*

output : 0000000000000043.page

2. 檢查看看數據是否存在

c_parser -6f pages-ibdata1/FIL_PAGE_INDEX/0000000000000043.page -t /tmp/t2.sql |head -20

這邊t2.sql是前置準備時生出來的建表sql
如果無誤的話，應該可以看到被刪掉的資料在上面。
P.S. 這邊的6 可以看一下c_parser --help 看對應的是不是自己資料的格式，以免復原後資料怪怪的(有亂碼之類的)

3. 接下來就可以開始生成恢復的sql了

./c_parser -6f pages-ibdata1/FIL_PAGE_INDEX/0000000000000043.page -t /tmp/t2.sql > dumps/default/user 2> dumps/default/user_load.sql

極重要 : 這邊後面dumps/default/裡面的兩個檔案名稱要和要恢復的table名稱一樣。

user 、user_load.sql

4. 接下來進到要恢復的database裡面，建表還有拿回資料，就可以了。

# 建表
[mysql]> source /home/root/t2.sql  
# 導入數據
[mysql]> source /home/root/undrop-for-innodb/dumps/default/user_load.sql

5. 接下來就是查table 的primary key 的 id -->> 找到page -->> 倒出 tableName_load.sql -->> 導回資料庫 的loop了

Refference:

留言

張貼留言

這個網誌中的熱門文章

淺談在Golang上面的物件導向

圖片
 從物件導向的語言轉到Golang常常會遇到，不知道該怎麼在Golang實作類似多型和繼承的功能。這是因為Golang根本不是物件導向的語言。 在網路上會看到一些文章，寫說可以使用可以embed來模擬繼承，但事實上embed的用途應該只是用來減少重複的程式碼，增加可讀性。像在io package裡面就很明顯，如intreface ReadWriter就是用Reader和Writer 兩個interface組合起來的。  使用embed struct的方式來模擬繼承。為了要可以被抽換注入，還是得要同時implement一個interface。這樣還不如直接implement interface就好了。  在Golang，唯一類似物件導向的東西只有 interface。只要有implement interface，就可以在宣告使用這個interface的地方使用。 個人的理解，Golang把繼承的概念且分成兩個部分：embed和interface。embed struct (interface) 負責擴增fields (method); interface負責讓不同struct可以有相同的調用方式  embed struct 的功能只是單純消除struct的field的重用而已。embed interface 也是如此，單純想要減少 method 裡面重複宣告 method 的程式碼。 簡單來說，就是   想要可以抽換，用interface; 想要減少重複可以用embed的方式包裝組合
閱讀完整內容

咖啡杯、隨行杯、保溫杯的清潔除臭

 對於常常在喝飲料的人來說，常常會製造很多拋棄式杯子的垃圾，為了環保，其實越來越多人開始使用保溫杯、隨行杯來代替一次性杯子。但這些可重複使用的杯子越用越久，就會開始出現異味。  杯子裡面氣味的來源分成兩大類，飲料原本含有物質的氣味、還有杯中細菌滋生產生的味道。以下各自說明 去除細菌的方式，除了使用滾水可以真的殺菌之外，其他的清潔方法都只能減少杯子上面的細菌含量， 因為常有的清潔方式都只是洗掉細菌而已，所以在杯子清潔後要自然風乾，而不是馬上放入不通風的地方，因為潮溼會增加細菌滋生。 而在清潔後，不能使用乾布擦乾得要自然風乾，因為即使是新的布，上面也是會有細菌存在，這樣反而會增加杯子上面的細菌含量。 但即使有在清洗，為什麼還是會有味道？因為當細菌開始滋生後，會開始產生滑滑的細菌膜，有了細菌膜之後就會開始變得很難清洗掉，所以杯子最好在使用完後馬上清潔，而不要 將杯子放到到隔天才清洗，因為此 時已經長了細菌膜了 ，雖然看起來是洗乾淨了，但事實上仍有細菌殘留在杯子上，只是我們肉眼看不到。 再來是除掉非細菌的異味  所有的除臭方法，除了使用吸收的方式（活性炭、芥末）之外，都是利用酸鹼中和的把氣味粒子轉成中性物質的方式來除味。所以其實可以在清洗乾淨後，依序使用食用醋、小蘇打來依次中和掉鹼性、酸性的氣味粒子。 以上都是上網查詢到整理好的資訊，所以也有可能有錯誤。 參考資料 https://themugglife.com/how-do-you-get-the-coffee-smell-out-of-a-mug/ https://www.amusing.pub/a/202207/269154.html https://read01.com/zh-tw/dEMNzBk.html#.YwikBHFBxPY https://www.yamab2b.com/why/4724300.html https://www.epochtimes.com/b5/22/1/21/n13521232.htm
閱讀完整內容

Reserved Instance 介紹

Reserved Instance 介紹 Aws Reserved Instance 介紹 因為公司收到AWS建議可以使用RI方案，但在官方文件上面寫得有點不清楚，所以在此寫下研究過後，瞭解到的部分。 [toc] 簡單說明 簡單來說，Reserverd Instance 就是一個你向AWS保證購買一段時間的Instance使用，所以AWS會給你較便宜的折扣去收錢。 Term 一個Term 代表購買的一次週期 目前只有1年、3年 這是官方賣的，但其實可以用AWS的market來買賣較短期的term的RI，有的話會在RI的購買search那邊顯示出來 3年會比1年便宜 AWS market上面賣的RI，也是別人向AWS購買後，發現不需要了，所以把剩下的賣出來，看有沒有人需要。這種的通常週期會比較短，但整個算起來價格還是比AWS預設的on-demand還要便宜。 付費方式 有 全部預付 、 部分預付 、 不預付 部分預付剩下的部分 和 不預付 ，會用RI的小時費用去算。 全部預付最便宜，部分預付次之， 不預付最貴，但還是比OnDemand還要便宜 。(因為你還是需要繼續付費到Term結束) Region Region: 可以在同個Region下，對 同系列(如t2) 且 同租用(如都是共享的) 且 同平台(如linux/Unix) 的instances 由小到大的正規化因素去分配。 簡單列幾個 執行個體大小 正規化因素 nano 0.25 micro 0.5 small 1 medium 2 large 4 xlarge 8 EX: 在Region Tokyo 買了一個t2.Medium的Linux RI，然後在Region Tokyo 裡面有執行一台t2.nano、一台t2.micro、一台t2.medium的instance，且他們都是Linux系統。 接下來AWS會自動去把t2.nano、t2.micro的所有使用都改成套用t2.Medium的折扣去收費。而t2.medium會有部分(1.25/2)會是套用t2.Medium的折扣，其他部分就依然使用OnDemand的價格。 Avai
閱讀完整內容