關於幾個MySQL環境問題的對比

有時候出現了環境問題，對比是一種很好的方式，如果對比得當，可以避免反覆的出現問題，可以根據對比的情況推理出一些可能出現的情況或者問題。
如果對比不當，很可能得出錯誤的結論。今天就簡單舉幾個例子來說明一下。
MySQL重啟的對比
之前出現過一次備機的硬體故障，但是慶幸的是幸虧是備機，備機上意味值有備庫，但是實際發現備機上的備庫和主庫沒什麼關聯，也是讓人直冒冷汗，那就搭建備庫吧，結果發現主庫沒有開啟binlog，這種情況下是沒有任何辦法的，所以在評估之後，發現還有一套環境也是同樣的問題，所以就申請了視窗時間來做重啟的工作，期間也對本身資料庫層面的引數考慮了最佳化，所以重啟涉及兩套環境，一套是5.5，一套是5.6，為了保險起見，5.6的mysql也保持了5.5的原有配置，沒有開gtid.重啟的過程實在沒有技術含量，但是重啟之後從資料庫日誌中出現了一些告警，告警資訊如下：
2015-12-22 07:42:23 26782 [Warning] Aborted connection 1238 to db: 'unconnected' user: 'unauthenticated' host: 'gate_app_4.172' (Got an error reading communication pack
ets)
2015-12-22 07:42:30 26782 [Warning] Aborted connection 1242 to db: 'unconnected' user: 'unauthenticated' host: 'gate_app_131.41' (Got an error reading communication pac
kets)
這個讓我們頗有些意外，對於這種情況，從對比的角度來看，有以下幾種場景。
對比場景1：是不是5.5,5.6的引數設定影響，是否是5.6中的bug，因為有問題的是5.6的mysql伺服器。
很顯然不是，因為5.6的配置我沒有修改其它的引數，只是開啟了binlog,原有的配置為了保險起見都沒有做變更。兩套環境的變更情況都是一樣。
對比場景2：是不是5.6的環境重啟的時候出了問題。
這個也可以排除，因為兩臺伺服器都是做重啟，另外一臺伺服器就沒有類似的問題。
對比場景3：對於這個問題，是否需要從應用端來檢視是否有長連線未釋放的情況
這個也進行了排查，在應用端來看，沒有發現相關的問題，而且涉及環境著實很多。
對比場景4：最近存在一些網路的變更，是否和dns的變更有一定的影響
對這個也求助了系統組進行協助，但是沒找到什麼相關的日誌。
對比場景5：重啟前和重啟後進行對比。
重啟前和重啟之後的日誌資訊是否有大的出入，當時檢視error.log的時候看到報出了好幾頁的告警資訊，也就沒有再往前翻更多的，看了4,5頁都是告警資訊，哪想到檢視之前的日誌，發現以前也有類似的問題。
所以這種對比，有一個基準，和其它的環境做對比，可能也會得出一些相關的結論，但是當前環境的重啟前後做對比更能體現出問題的根源，如果之前就存在此類的問題，那就說明這是個歷史遺留問題，這些應用已經可以停止嘗試連線了。

MySQL匯入dump
前端時間做幾套基於雲伺服器下的MySQL資料遷移，碰到了幾個問題，當時還比較困擾我。
因為資料量不大，所以就採用了mysqldump做了邏輯匯出，然後直接在目標環境邏輯匯入。因為是新環境，所以有些庫匯入沒有任何問題，有一個庫總是在匯入的時候會自動退出。
報錯內容為:
 ERROR 2013 (HY000) at line 8441: Lost connection to MySQL server during query
當然對於這個問題，用了一下幾個對比場景來嘗試。
首先環境的記憶體是16g，存在3個dump,分別為10g,20g,30g，最開始為了省事，我就開啟了三個nohup的程式去併發匯入，資料在不同的資料庫中。
場景1：  併發匯入3個dump，匯入失敗
場景2：  序列匯入也報錯，接著使用序列的方式匯入，依舊失敗，因為自己也是稍後檢視的日誌，發現匯入失敗，不確定全部都順利完成。
場景3：  當然還在聯調階段，所以我還有一些時間來多做一些測試，然後匯入20G，發現依舊失敗。
場景4：按照對比的思路，30g肯定也是匯入不了，確實匯入不了，不過發現30g的dump中在某一個表分割槽時匯入就會失敗
場景5：嘗試對30g的dump中的這個分割槽表單獨匯入，發現依舊存在問題。不過所幸開始檢視日誌，發現原來是 oom-killer導致， 這個和剩餘記憶體少密切相關，當然也和swap相關。
場景6：發現這些雲伺服器都沒有配置swap，新增了swap之後，  匯入10g的dump，就成功了。
場景7： 匯入20g,也成功了，但是swap使用率在10g左右，swap配置了16G,為什麼在10g左右徘徊呢，這個和swap的預設配置使用率有關，預設是60%，也就是9.6G左右，和現象中的10g是一致的。那麼為什麼會消耗大量的swap呢，初步懷疑是因為線上匯入，因為業務上開始做聯調了，不能夠停應用，所以就出現了線上匯入資料的情況。
場景8：那麼接著匯入30g的dump,是否依舊成功呢，遺憾的是這次還是失敗了， 因為發生了oom-killer，對應的執行緒被終止了，swap徹底釋放,swap使用量一下子重置為5M了。
場景9： 這個時候再次嘗試匯入30g的dump,就沒有問題了，不過因為線上匯入，會有一些鎖等待，而且對於資源的消耗著實夠高，swap使用率到了10G左右
場景10: dump已經匯入成功，為什麼swap沒有釋放呢，一種方式就是重新掛載swap分割槽，但是讓人鬱悶的是還是因為記憶體不足。報出了下面的錯誤。
#swapoff -a
swapoff: /home/swapfile: swapoff failed: Cannot allocate memory
那麼這種情況改怎麼辦，目前來看重啟是一個唯一奏效的方案了。聯絡應用重啟，但是一直沒協調下來，所以就這樣耽誤了幾天。
場景11：過了幾天之後我再次檢視，發現swap已經自動重置了，而重置的原因還是oom-killer，看來應該是有個連線被強制終止之後，觸發了oom-killer,然後swap徹底釋放。
那麼這麼多看起來瑣碎的場景，有個問題就是為什麼記憶體總是不足呢，除了swap還應該有些原因吧，最後發現還有一個原因就在於buffer_pool_size設定過大，本來16g的記憶體，結果buffer_pool_size竟然設定了24G，為什麼會出現這種低階錯誤呢，追根溯源發現原來使用的模板只校驗redhat,沒有校驗centos，而這臺伺服器上安裝的恰恰是centos，所以在初始化引數的時候給直接設定了成了24G,所以這個模板也存在一些問題，本身的校驗邏輯還是不夠嚴謹。

對比了一圈，發現對比有時候可以幫助我們分析問題，有的時候也會誤導我們，凡事有度，當然如果做一件事情，沒有任何的輸出和結論，也是沒有實際意義的。