MySQL Cluster恢复过程记

 最近在项目的生产环境中使用了mysql-mmm来提高数据库的可用性和处理能力。在项目初期，mysql-mmm安装、配置和部署对我们开发人员一直都是透明的。于是一个“美好”的愿望开始在心中滋生：我们不需要管理数据库，一旦有问题就会系统管理人员过来修复。可是，随着项目的深入，这个愿望也在逐步破裂。由于某些开发人员不当操作（当然，开发人员是不应该具有直接操作数据库的权利的，这是管理上的问题。），导致MySQL Cluster主从状态不统一，无法完成同步，从而造成主程序无法启动。这时，我们的最初创建环境的系统管理人员，却因为其他项目无法抽身，而他当初的警告也让我们不敢“越雷池半步”。中间的几次问题，都通过不同的方法临时解决了：邀请了其他项目组的DBA、写了脚本定时监控mysql-mmm的状态等等。可是到了9月30号这一天一切都变了。数据库又一次毫无征兆的崩溃了。这次更严重：一台slave无法启动，两台slave无法同步，只剩下master，还在苟延残喘（这个词有点过分！）。

        难道MySQL Cluster真的有那么麻烦吗？终于忍无可忍了，不能再把希望寄托到别人身上！在把主程序的数据库读写都切换到了master上以后，开始尝试恢复MySQL Cluster的状态。

        继续之前，交代一下MySQL Cluster的配置：典型的writer/reader。db01和db02为master，db01，db02都为writer，同时db02还作为reader，db03和db04都是slave，作为reader。其中db04已经无法启动。

        为了防止万一失败不会造成更坏的影响，选择了db04作为练手的对象。

        问题1：MySQL无法启动