一大早就被电话吵醒了,云某项目数据库全挂了,启动不了(睡得太死,没听到报警短信),吓得不轻啊!
电话中说所有mysql数据库主库都启动不了,但从库正常,怀疑是主库去连其它阿里云的主库了。这些数据库,以前是从阿里云迁移到idc机房的,因此他有这个判断。
赶紧打开电脑,连* * *,登录其中一个数据库服务器,试着执行如下命令启动mysql服务
(root@bbsmysql121备份)# mysqld_safe mysql用户=,
启动失败,又换一台数据库服务器尝试,还是失败。考虑到所有的数据库都不能启动,因此可以初步判定,可能是数据库宿主机的问题导致的。
数据库的底层设计是两台物理节点虚拟化,外加一台物理机做备份。其中一台物理机的虚拟机全部做mysql主库,另一台物理机的虚拟机做mysql从库。
先放弃在虚拟机进行故障排查,赶紧登录宿主机系统。接下来,从两个方面排查问题所在。
u虚拟化后台管理系统
发现存储被塞满了,问题很严重。
u ssh登录宿主系统debian
[6885005.756183]缓冲I/O错误alt="干掉一堆mysql数据库,仅需这样一个shell脚本(推荐)">
再登其它服务器,分区/dev/sdb1也是使用了90%以上。进入目录/数据,运行如下指令查看目录空间占用情况:
[root@cumysql121数据]# du - h *
4.0 k备份
59 g db_pkg
59 g mysql_db
(root@cumysql121数据)#光盘备份
(root@cumysql121备份)# du - h *好家伙,好几个50多G的目录(写这个文章时,我已经删掉了,没有留存记录),这些文件,从目录名称上看,应该是备份数据库自动生成的。不管它,先删除。
肯定有人在系统做了自动任务,用指令crontab - l查看,果然有发现:
# !/bin/bash
/usr/local/xtrabackup/bin/innobackupex——defaults-file——用户==/etc/my . cnf中所做的根——passwor=' + N4dohask + MsLhG/数据/备份/
找到/数据/备份/* -mtime + 1 - rm - fr {} \;
~初一看这个脚本没什么问题,再仔细看,最后一行是符号“~”,有问题啊!写脚本的人的意图是每天进行一次备份数据库备份,然后删除前一天的历史备份数据,这样就不会把磁盘塞满了。
但是这有两个致命的问题,这里分别描述之。
<强>备份策略错误
有专门的备份系统,应该把数据备份到该系统上,而不是本地备份。
<强>手段错误
备份脚本写好以后,应该手动执行,以验证其正确性。而不是写完,直接扔在上边不管。
<>强修复磁盘错误
紧急联系机房,请技术人员把KVM/连接到宿主机,万一系统引导不了,可远程查看或者进入单用户模式进行fsck一类的修复操作。
Ssh连宿主机系统debian,确认被塞满的磁盘空间被释放,然后执行重启重启系统。几分钟以后,系统正常引导。
<强>后续操作
查看系统日志,没有磁盘io报错,创建目录及文件,正常;启动各虚拟机,启动其上的数据库,都正常了。
通知各路人马,从业务层面检查是否正常。片刻,短信来一堆恢复信息,心里踏实多了。不用说,是项目方的sa干的这个好事,并且没有通知任何人。
干掉一堆mysql数据库,仅需这样一个shell脚本(推荐)
