MySQL Cluster恢复过程记-阿里云开发者社区

开发者社区> 数据库> 正文
登录阅读全文

MySQL Cluster恢复过程记

简介:         最近在项目的生产环境中使用了mysql-mmm来提高数据库的可用性和处理能力。在项目初期,mysql-mmm安装、配置和部署对我们开发人员一直都是透明的。于是一个“美好”的愿望开始在心中滋生:我们不需要管理数据库,一旦有问题就会系统管理人员过来修复。

        最近在项目的生产环境中使用了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 -hdu -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的配置,这个是接下来要解决的问题。

    

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享: