一次驚心動魄的Percona XTRADB Cluster資料修複過程【MySQL】

一次驚心動魄的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