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