【国庆】记一次mysqld_safe引发mysql进程故障

今天是举国欢庆的日志，身为奋青的我，学习和工作，首日计划安排必须是学习任务呀；但是今天心血来潮，Mariadb密码忘记了，于是巴拉巴拉的执行"mysqld_safe --skip-grant-tables &"这个神技能，打算跳过密码验证，直接登录到数据库中，更新密码；mysqld_stfe这条命令的同学应该清楚，首要条件时stop数据库，在执行mysqld_safe --skip-grant-tables &；这样才能进行更改登录数据库用户的密码；更新之后，发现一个很诡异的问题；

【悬案疑点】

这个msyql进程是存在的，但是查看mysql状态是关闭的，并且mysql3306端口也是监听的状态，这就奇怪了，我已经为了实现免密更新密码，特意干掉了mysql，为啥进程和端口仍然未停止呢？如图1~3所示

随后，修改完密码，我尝试system restart mariadb，查看mysql状态，仍然异常，此时kill -9都未能停止mysqld_safe莫名引起的神秘进程；

最后呢，tail /var/log/mariadb/mariadb.log日志，发现ERROR] mysqld: Table './mysql/user' is marked as crashed and should be repaired；这是user表损坏，干掉mysqld进程，mysqld_safe这个癞皮狗进程就会将其重新将mysql端口和进程拉启来

 【解决方案】

当我们修改完mysql登录用户验证密码之后，如何让mysql状态恢复正常，这才是我们的最终目的

竟然知道了什么原因导致mysql数据库异常(端口和进程干不掉)，那就好办了，我们先ps -ef | grep mysqld_safe看看它这个赖皮狗是否起了进程，如果起了的话，二话不说直接干

杀死之后呢，我们ps -ef | grep mariadb查看mysql进程，没有直接影响，那么我们同样也是干，这个时候，这个进程便不会启动啦

最后呢，我们直接restart重启数据库即可恢复正常，完美~

【小结】

遇到这种问题，我们可以直接reboot通过重启系统的方式来解决，但是，我们不能直接这样做，难道我们每次遇到问题都重启系统来解决吗？这样，我们永远都不能发现问题，当一个问题reboot重启解决不了，那又该如何呢？换硬件服务器？卸载数据库，重新安装？呵呵，这不太现实吧，这样会让别人直接拿刀分分钟砍死你；所以说，我们遇到问题，首先冷静，尝试自己排查问题，借助谷歌百度，抓住关键性错误信息；一触即发，我们运维人员核心竞争力 就是处理问题能力和对待问题的态度，要有自己的思路和想法，这样才能立于不败之地~

ps：本章还有待更新~后续会更新mysqld_safe的相关知识点；点击关注，精彩内容，有你好看~

............................