一次惊心动魄的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先做在前面了。附另一种数据恢复方案（没有实际验证过）：

一次惊心动魄的Percona XTRADB Cluster数据修复过程【MySQL】