问题描述

1 mysql数据库5.6无法正常启动

2 直接复制替换innodb的frm和idb文件来新增数据表导致的问题

3 innodb文件ibdata1，ib_logfile0，ib_logfile1损坏，数据不一致

4 没有sql备份，无法正常登陆和导出当天数据

注意事项

innodb的表不能直接复制替换frm和idb文件，而是使用工具正常导入导出，myisam表可以直接复制替换文件

解决方法

1 开启mysql错误日志，观察日志来判断数据库什么问题(此次问题比较清楚，innodb损坏，ibdata1损坏导致)

2 innodb_force_recovery (0-6级别) 此次使用6强制启动

1(SRV_FORCE_IGNORE_CORRUPT):忽略检查到的corrupt页。

2(SRV_FORCE_NO_BACKGROUND):阻止主线程的运行，如主线程需要执行full purge操作，会导致crash。

3(SRV_FORCE_NO_TRX_UNDO):不执行事务回滚操作。

4(SRV_FORCE_NO_IBUF_MERGE):不执行插入缓冲的合并操作。

5(SRV_FORCE_NO_UNDO_LOG_SCAN):不查看重做日志，InnoDB存储引擎会将未提交的事务视为已提交。

6(SRV_FORCE_NO_LOG_REDO):不执行前滚的操作。

当设置innodb_force_recovery大于0后，可以对标进行select、create、drop操作，但insert、update或者delete这类操作是不允许的

3 innodb_force_recovery=6 正常启动mysql后，无法使用navicat工具导出数据量大的的数据库，正常工具导出还会导致数据库崩溃(此处没有最近的sql备份，只有损坏后数据库目录直接备份，但是ibdata1损坏，所以这个备份没有意义，所以此处还是要导出正常的sql备份，用来恢复当天最近的数据)

4 尝试使用innochecksum  -f ibdata1工具来修复ibdata损坏,但是没有效果

5 使用mysqldump命令进行导出(此处遇到问题，和原来业务的数据编码问题，重新创建mysql环境，数据库创建问题，表创建问题，索引创建问题)

1 数据编码问题，此处并不是普通的中文乱码问题，而是编码: JUSTEP154053; 提示: KSQL语法错误，源程序服务tomcat启动问题

这个编码问题分为两步 ：tomcat启动报错，数据库和表的编码问题，tomcat正常启动后里的程序页面报错，这是数据的编码问题

2 此处遇到数据库，表创建，数据问题，手动创建新的utf-8，但是不生效，虽然都和原环境一直，但还是会出现编码报错，业务有问题

3 解决无论导入和导出都需要加上--default-character-set=utf8(防止编码: JUSTEP154053，防止mysql错误导入ERROR 1064 (42000))

4 此次为了快速解决，使用了原来2018-04月的备份数据库，使用原来数据库的库和表结构，清空数据

5 导出来加-t 只导出数据，不导出表结构

6 解决步骤

1 导出三个库所需的数据 --default-character-set=utf8 只导出数据，不导结构

2 确保导出备份数据可以使用后，删除原有数据库文件

3 备份MySQL数据目录下的ib_logfile0、ib_logfile1、ibdata1三个文件，然后将这三个文件删除

4 innodb_force_recovery = 0 重新启动mysql 重建 ib_logfile0、ib_logfile1、ibdata1 此时所有数据表都无法打开

5 重新导入数据文件 --default-character-set=utf8 导入数据

mysql数据恢复通过frm和idb文件(此处没有使用)

记录参考https://blog.csdn.net/Sonny_alice/article/details/80198200

整个恢复过程其实可以总结为下面几步：

一：无表数据结构

(1)：恢复表结构

(2)：复制出来创建表的sql语句

(3)：恢复表数据(在恢复表数据的时候，首先需要解除当前创建的表与默认生成的.ibd文件间的关系，接着将要恢复数据表的.ibd文件与当前创建的表联系起来即可)

(4)：alter table songlyric discard tablespace;alter table songlyric import tablespace;