MySQL Cluster恢复过程记

9404803

　　最近在项目的生产环境中使用了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无法启动
　　现象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日志，找到相应的提示，根据错误提示进行相应的操作。由于现场丢失，只能在这里给出错误原因：
　　  a. 日志文件夹已满，无法写入。MySQL的数据文件和日志文件并没有放在默认的/var/lib/mysql下面，而是另外指定了目录/opt/mysql/data和/opt/mysql/log。通过df -h和du -h --max-depth=1命令查看，发现该目录/opt/mysql目录已经满了，于是清空了/opt/mysql下面的所有文件，重新启动，还是同样的问题
　　  b. 日志文件和数据文件不存在。于是重新创建data（数据）和log（日志）两个目录，根据my.cnf里面的配置，分别将/var/lib/mysql下面的ibdata1和ib_logfile0、ib_logfile1分支复制到数据和日志目录中。重新启动，问题依旧。
　　  c. mysql用户无权读取data和log目录。和其他几台服务器上的目录比较结合错误日志发现，原来上面两个文件夹是由root用户创建的，mysql用户没有读写权限。chown -R mysql.mysql data修改目录所有者。重新启动，同样错误信息跃然于眼前。
　　  d. mysql无法在现有的数据文件和日志文件上进行操作。将ibdata1和ib_logfile0、ib_logfile1删除，重新启动。终于启动成功，回到目录下查看，已经新建了ibdata1和ib_logfile0、ib_logfile1。
　　

　　  问题2：无法导入dump文件。
　　  服务启动成功后，下面就是按照MySQL-MMM安装指南进行配置了。从db01上dump出当前的数据库内容，然后在db04上导入。由于导入是在9月30号下午进行，当时为了不耽误班车，强行退出了导入进程，就出现这个错误http://blog.csdn.net/mydeman/article/details/6843398。
　　  今天在删除了一些比较大的并且不再使用的数据库后（一定要记得备份！！），dump出来的数据文件小了很多，可是在导出过程中直接退出了。通过ps查看，发现mysql已经停止，而且无法重启。查看错误日志，发现如下信息：
　　  [ERROR] /usr/sbin/mysqld: Disk is full writing './myapp/session.MYD' (Errcode: 28). Waiting for someone to free space... (Expect up to 60 secs delay for server to continue after freeing disk space)
　　   原来在导入时，数据库被创建到了默认的/var/lib/mysql下面，而这个目录由于分配的空间很小，所以被占满了。通过mv命令，将除了mysql以外的其他数据库都移动到/opt/mysql/data/下面，然后通过ln -s建立连接。数据正常启动，重启导入进程，Bingo！
　　

　　  问题3：无法完成执行CHANGE MASTER命令。
　　  在db04上数据文件导入完毕，按照MySQL-MMM安装指南完成后续步骤，启动SLAVE。然后到mysql-mmm admin节点上通过mmm_control set_online db04，将db04上线。mmm_control show查看状态一切正常。
　　 安装恢复db04的步骤，恢复db02和db03。前面的步骤都很顺利，可是执行CHANGE MASTER命令时出现了错误，日志中的错误信息：
　　  Failed to open the relay log '//opt/mysql/log/mysql-bin-slave1.005457' (relay_log_pos 147636219)。
　　  到/var/lib/mysql目录下，发现其中已经存在了master.info和relay-log.info两个文件。查看master.info文件，其中还是上一次同步时设置的内容。删除这两个文件。重新执行CHANGE MASTER命令。
　　  
　　  由于在之前已经安装了mysql-mmm的组件，因此这次恢复过程没有涉及到mysql-mmm的配置，这个是接下来要解决的问题。