干掉一堆mysql数据库，只需这样一个shell脚本
发布时间：2022-03-21 08:59:37 所属栏目：MySql教程 来源：互联网
导读：一大早就被电话吵醒了，云某项目数据库全挂了，启动不了（睡得太死，没听到报警短信），吓得不轻啊！ 电话中说所有mysql数据库主库都启动不了，但从库正常，怀疑是主库去连其它阿里云的主库了。这些数据库，以前是从阿里云迁移到idc机房的，因此他有这个判
|
一大早就被电话吵醒了，云某项目数据库全挂了，启动不了（睡得太死，没听到报警短信），吓得不轻啊！ 电话中说所有mysql数据库主库都启动不了，但从库正常，怀疑是主库去连其它阿里云的主库了。这些数据库，以前是从阿里云迁移到idc机房的，因此他有这个判断。 赶紧打开电脑，连***，登录其中一个数据库服务器，试着执行如下命令启动mysql服务 [root@bbsmysql121 backup]#mysqld_safe –user=mysql & 启动失败，又换一台数据库服务器尝试，还是失败。考虑到所有的数据库都不能启动，因此可以初步判定，可能是数据库宿主机的问题导致的。 数据库的底层设计是两台物理节点虚拟化，外加一台物理机做备份。其中一台物理机的虚拟机全部做mysql主库，另一台物理机的虚拟机做mysql从库。 先放弃在虚拟机进行故障排查，赶紧登录宿主机系统。接下来，从两个方面排查问题所在。 ü 虚拟化后台管理系统 发现存储被塞满了，问题很严重。 ü ssh登录宿主系统debian [6885005.756183] Buffer I/O error on dev dm-16, logical block 34667776, lost async page write [6885005.757292] Buffer I/O error on dev dm-16, logical block 34667792, lost async page write [6885005.758210] Buffer I/O error on dev dm-16, logical block 34667808, lost async page write [6885005.759079] Buffer I/O error on dev dm-16, logical block 34667824, lost async page write [6885005.759922] Buffer I/O error on dev dm-16, logical block 34667840, lost async page write [6885005.760723] Buffer I/O error on dev dm-16, logical block 34667856, lost async page write 系统日志/var/log/messages发现大量的磁盘io错误。 综合上述发现，基本可以断定是磁盘出了问题：一个问题是proxmox划定的存储空间被塞满，另一个是磁盘io错误。知道问题所在以后，接下来的处理方案有两个：修复错误或者把从库提升为主库。考虑到待机问题，还是尽量争取修复主库吧，实在不能修复，再用第二套方案（提升从库）。 释放磁盘空间 为什么磁盘空间会塞满呢？应该有人在虚拟机上干了啥，而且可能是每个虚拟机都进行相同的操作，才会导致宿主机磁盘空间迅速填满。随便登录某个运行mysql数据库的虚拟机，执行命令 df-h 再登其它服务器，分区/dev/sdb1也是使用了90%以上。进入目录/data，运行如下指令查看目录空间占用情况： [root@cumysql121 data]# du -hs * 4.0K backup 59G db_pkg 59G mysql_db [root@cumysql121 data]# cd backup [root@cumysql121 backup]# du -hs * 好家伙，好几个50多G的目录（写这个文章时，我已经删掉了，没有留存记录），这些文件，从目录名称上看，应该是备份数据库自动生成的。不管它，先删除。 肯定有人在系统做了自动任务，用指令crontab –l 查看，果然有发现： #!/bin/bash /usr/local/xtrabackup/bin/innobackupex --defaults-file=/etc/my.cnf --user=root --passwor='+N4dohask+MsLhG' /data/backup/ find /data/backup/* -mtime +1 -exec rm -fr {} ; ~ 初一看这个脚本没什么问题，再仔细看，最后一行是符号“~”,有问题啊！写脚本的人的意图是每天进行一次备份数据库备份，然后删除前一天的历史备份数据，这样就不会把磁盘塞满了。 但是这有两个致命的问题，这里分别描述之。 备份策略错误 有专门的备份系统，应该把数据备份到该系统上，而不是本地备份。 手段错误 备份脚本写好以后，应该手动执行，以验证其正确性。而不是写完，直接扔在上边不管。 修复磁盘错误 紧急联系机房，请技术人员把KVM over 连接到宿主机，万一系统引导不了，可远程查看或者进入单用户模式进行 fsck一类的修复操作。 Ssh连宿主机系统debian，确认被塞满的磁盘空间被释放，然后执行reboot重启系统。几分钟以后，系统正常引导。 后续操作 查看系统日志，没有磁盘io报错，创建目录及文件，正常；启动各虚拟机、启动其上的数据库，都正常了。 通知各路人马，从业务层面检查是否正常。片刻，短信来一堆恢复信息，心里踏实多了。不用说，是项目方的sa干的这个好事，并且没有通知任何人。 私下给他说，这事自己跟其它人解释，以后干有风险的事情，最好相互通知一下。 以上所述是小编给大家介绍的干掉一堆mysql数据库，仅需这样一个shell脚本详解整合，希望对大家有所帮助，如果大家有任何疑问请给我留言，小编会及时回复大家的。 （编辑：云计算网_泰州站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
浙公网安备 33038102330476号