一次驚心動魄的Percona XTRADB Cluster資料修複過程【MySQL】,perconaxtradb
一次驚心動魄的Percona XTRA Cluster DB資料修複過程
2014.12.27日中午約12:30,電話響起,是同事YI的電話,告之說庫中出現大量死結,用“service mysql restart”無法重啟。這裡我先說明下:我們在移動音樂項目中使用的是
Percona XTRA Cluster DB,在產生環境中,建議最低是3個節點。但移動移動機器緊張為由,導致資料庫運行在單一節點上。雖然此前已經告之了這樣導致單點故障,無法保障HA。但移動不以為然,終於導致資料庫崩潰發生了。
問題發生後,先用“/etc/init.d/mysql bootstrap-pxc”啟動資料庫,但顯示“table not exists”。分析後,判斷這是資料庫崩潰導致資料丟失。之後,立即投入資料恢複的緊張工作。
恢複方案為:
1、建立資料庫;
2、建立表;
3、discard資料表空間;
4、拷貝備份的.ibd檔案;
5、import資料表空間;
至此,在建立庫上恢複正常。
但又一個新問題,程式中已經引用了之前的資料庫名,必須改回原資料庫名。至此,立即動手。
方案為:
1、刪除原資料庫;
2、用原庫名建立資料庫;
3、拷貝原備份目錄(idbata、.ibd檔案)
4、之後重複上面的恢複方案
後探索資料庫無法正常啟動,把my.cnf改為"innodb_force_recovery = 4"。資料庫可以啟動,但無法建立、刪除和更新。這種情況,一種方案是把資料dump出來,
再dump進去。為此,建立了另一個資料庫。這次是採用的MySQL官方社區版。在資料DUMP的過程中,發現有的表無法dump。後採用聯邦表把資料匯入進去。在匯入的過程中,還發生了“欄位太長,匯入失敗”的問題,尋找後把my.cnf中改為“# sql_mode=NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES”問題解決。
至此,這次Mysql崩潰導致的資料恢複工作完成,資料沒有丟失。下面要做的就是MySQL HA了。主要指令碼如下:
alter table AUTH_USER discard tablespace;
cp -f /data/munion_db_bak/munion_db/AUTH_USER.ibd /data/munion_db/munion_db
alter table AUTH_USER import tablespace;
mysqldump -u root -pmunion123 -c --default-character-set=gbk munion_db AUTH_USER > /data/dump/AUTH_USER
mysqldump -u root -pmunion123 --default-character-set=gbk munion_db AUTH_USER < /data/dump/AUTH_USER
此次Mysql資料恢複是次難得的經驗,當然最好是不要出現這樣的問題。這就需要把HA先做在前面了。附另一種資料恢複方案(沒有實際驗證過):
1. drop these tables from mysql:
innodb_index_stats innodb_table_stats slave_master_info slave_relay_log_info slave_worker_info
2. delete all .frm & .ibd of the tables above.
3. run this file to recreate the tables above (source five-tables.sql).
4. restart mysqld.
Cheers, CNL