今天是舉國歡慶的日誌，身為奮青的我，學習和工作，首日計劃安排必須是學習任務呀；但是今天心血來潮，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的相關知識點；點擊關註，精彩內容，有你好看~

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

【國慶】記一次mysqld_safe引發mysql進程故障