一次惊心动魄的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