MySQL InnoDB 崩溃恢复过程 前言
最近一个正在进行的项目，性能测试场景中包含MySQL 为较大压力的应用程序提供服务，Linux服务器CPU占用100% ，OS 不可用，我写了一个吃CPU的shell脚本来不断的跑，结果把服务器跑挂了，手动重启了服务器后，发现MySQL起来的时间需要非常长，为大家所不能接受
MySQL相关信息 5.0.67 InnoDB Buffer Pool Size为36G ,innodb_flush_log_at_trx_commit = 1，innodb_log_file_size = 900M
，当时候的服务器情况比较糟糕，CPU占用100% ，ssh也登录不进去，维持了一段时间后才进行重启，所以没有收集到最重要的崩溃之前的MySQL内部信息 整个的恢复过程用了6个小时
这个时候，引发了我们的反思:
1. 我们的MySQL压测模型没有针对不同版本的MySQL进行崩溃恢复压测 所以出现这个崩溃恢复的问题，我们只能补回来这个测试，针对不同版本的MySQL(MySQL 5.0.67 和MySQL5.1.xx)，需要进行相同TPS的场景下进行kill -9 pid (mysqld)的测试，掌握一手的崩溃恢复时间，为将来线上出现MySQL崩溃，做最好的准备
2. 我自己对MySQL InnoDB崩溃恢复的过程不是非常了解,导致MySQL崩溃之前没有去采集有参考价值的数值，这点需要加把劲
这一篇是前言，下一篇，我会对MySQL InnoDB的崩溃恢复过程做详细的介绍