mysql cluster 数据恢复_一次惊心动魄的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

作者：china_world 发表于2014-12-31 16:24:42 原文链接

阅读：45 评论：0 查看评论