MySQL Cluster恢复过程记

最近在项目的生产环境中使用了mysql-mmm来提高数据库的可用性和处理能力。在项目初期，mysql-mmm安装、配置和部署对我们开发人员

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

更多关于MySQL Cluster的详细信息，或者下载地址请点这里

难道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无法启动

现象1：使用service mysql start启动时，进度一直持续。

备份现有的配置文件my.cnf，重新安装MySQL。安装后MySQL启动正常，将备份的my.cnf，恢复到/etc/，重新启动MySQL。出现错误：

现象2：Starting MySQL. ERROR! Manager of pid-file quit without updating file.

查看/var/lib/mysql/下面的*.err日志，找到相应的提示，根据错误提示进行相应的操作。由于现场丢失，只能在这里给出错误原因：