不能輕視的MySQL重啟過程

不能輕視的MySQL重啟過程

資料庫的重啟看似是一件非常簡單，沒有技術含量的活，這是我以前說的話。而這句話簡直是戳中了我的痛點。這種活真是太有技術含量了，高深到讓人需要注意太多的東西，需要做非常多的前期功課。
前段時間，發生了一起硬體問題，發現某一台mysql備程式庫伺服器出現了硬體錯誤，因為是從程式庫伺服器的故障，所以就沒有很著急得去處理，簡單排查發現從庫硬體問題無法修複，就申請新機器去嘗試重搭從庫了。初步分析問題情況如下：

但是讓人意外的是準備線上搭建從庫的時候，發現主庫中沒有開啟binlog,所以我們看到的從庫其實是一個獨立的主庫，而個真正的主程式庫伺服器也已經裸奔了很長時間，其實沒有從庫，想想這種情況，就讓人後背發涼，需要趕緊修複這個問題。這個時候發現問題情況如下：

所以就簡單進行了評估，發現還有一台mysql伺服器也沒有開啟binlog,而且也沒有從程式庫伺服器，於是這個問題的修複就是需要重新搭建兩個從庫。而binlog的開啟需要重啟mysql資料庫，所以任務就很自然變成了在特定的維護視窗去重啟這兩台mysql主程式庫伺服器，然後在這個基礎上搭建從庫。
所以這個時候問題情況如下：

對於開啟mysql的binlog就跟Oracle開啟歸檔模式差不多，你說這個過程有多複雜，其實就是在重啟的過程中重新初始化一番。
我們確定了詳細的時間範圍，操作步驟，和其他team互相協調配合等等，看起來工作已經做的很充分了。
dba這邊也沒有掉以輕心，除了開啟binlog，也向mysql的同事諮詢看還有什麼參數可以考慮最佳化的，所以這個工作看起來重啟也著實不算吃虧，還順便能夠調優一下。
計劃是下面的情況：

一切都安排就緒，在等待重啟的幾天時間裡，也做了異地的備份，以備不時之需。
對於這次重啟，感覺也沒有什麼需要特別注意的了，也甚至考慮了要不要設定crontab來重啟，要不要使用自動化指令碼來搭建備庫等。因為自己也還算mysql新手，還是摸清了門路再放開手腳。
計劃就在今天早晨，和系統那邊的約定是在早晨5點左右。大晚上也沒睡好，半夜醒來就怕睡過了頭，然後反反覆複醒來，最後感覺老是醒來看手機，電話太吵影響家人，索性抱著被子到客廳裡去睡了，結果睡到了5點半，終於電話來了，開始幹活。
首先是使用show processlist檢查是否串連已經關閉，還得確認一番，最後準備停mysql庫了，發現pid檔案怎麼沒了。
# /etc/init.d/mysql stop
MySQL (Percona Server) PID file could not be found![FAILED]
# ll /home/mysql/mysql.pid
ls: /home/mysql/mysql.pid: No such file or directory
然後還得偽造一個pid檔案，在裡面手工填入mysqld的進程號。
然後再次嘗試就沒有問題了，也算小小虛驚一場。
然後停完服務，開始替換參數配置，重啟服務，一切都進行的很自然。還準備回頭先睡一會，再搭從庫。
同事突然反應說error.log裡面有很多的警告。
一部分是串連的問題，內容如下：
2015-12-22 07:57:41 26782 [Warning] Aborted connection 1417 to db: 'unconnected' user: 'unauthenticated' host: 'test_app_128.100' (Got an error reading communication pa
ckets)
2015-12-22 07:57:47 26782 [Warning] Aborted connection 1418 to db: 'unconnected' user: 'unauthenticated' host: 'test_app_4.176' (Got an error reading communication pack
ets)
這個部分初步懷疑是不是mysql的參數設定導致的，但是變更的只有log_bin,log_bin_index,cache_size其它的參數都沒有動。兩台mysql主庫的參數修改都是一樣的，值得一提的是兩台mysql庫，一台是5.6，一台是5.5，如果說是版本中的問題導致，那也有些牽強。而且另外一台mysql主庫中也有警告，但是警告非常少。
對於這個問題也排查了很多因素，從應用端沒有反饋得到錯誤資訊，我們這邊也在測試，排除了使用者名稱密碼的錯誤，慢查詢的原因，初步懷疑是應用端沒有完全關閉串連導致。
另外一部分是mysql資料字典的問題。
2015-12-22 18:19:51 25011 [Warning] InnoDB: Cannot open table mysql/innodb_table_stats from the internal data dictionary of InnoDB though the .frm file for the table exists. See http://dev.mysql.com/doc/refman/5.6/en/innodb-troubleshooting.html for how you can resolve the problem.
最開始看到這個錯誤還是讓人感覺很奇怪，但是讓人無奈的這類錯誤在1年前就已經存在了，我只是重啟了mysql庫，其實應該順帶修複這個問題，但是沒有引起重視。這類修複還是需要重建這幾個資料字典表了，可能需要動ibdata,重啟又是需要配合應用來尋找合適的視窗了。
所以通過這個案例，可以看到重啟是多麼的有技術含量，重啟的過程中起到了承上啟下的作用，需要充分調研問題，查看是否有遺留問題，一併加以解決，對於其它不明確的問題也需要不斷確認，最終逐步深入，應該會把重啟中的坑都填平，自己走平坦了，以後大家都方便，這也是規範的起始，讓它能夠落地。

本文永久更新連結地址：