当前位置:Gxlcms > mysql > MySQLCluster恢复过程记_MySQL

MySQLCluster恢复过程记_MySQL

时间:2021-07-01 10:21:17 帮助过:25人阅读

bitsCN.com

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

摘自 mydeman的学习日志

bitsCN.com

人气教程排行