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

關於幾個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,所以這個模板也存在一些問題，本身的校正邏輯還是不夠嚴謹。

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

本文永久更新連結地址：