有時候出現了環境問題，對比是一種很好的方式，如果對比得當，可以避免反復的出現問題，可以根據對比的情況推理出一些可能出現的情況或者問題。

如果對比不當，很可能得出錯誤的結論。今天就簡單舉幾個例子來說明一下。

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

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

來自 “ ITPUB博客 ” ，鏈接：http://blog.itpub.net/23718752/viewspace-1970096/，如需轉載，請注明出處，否則將追究法律責任。

總結

以上是生活随笔為你收集整理的多个mysql 环境_关于几个MySQL环境问题的对比的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。