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

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

MySQL重啟的對比

之前出現(xiàn)過一次備機的硬件故障，但是慶幸的是幸虧是備機，備機上意味值有備庫，但是實際發(fā)現(xiàn)備機上的備庫和主庫沒什么關(guān)聯(lián)，也是讓人直冒冷汗，那就搭建備庫吧，結(jié)果發(fā)現(xiàn)主庫沒有開啟binlog，這種情況下是沒有任何辦法的，所以在評估之后，發(fā)現(xiàn)還有一套環(huán)境也是同樣的問題，所以就申請了窗口時間來做重啟的工作，期間也對本身數(shù)據(jù)庫層面的參數(shù)考慮了優(yōu)化，所以重啟涉及兩套環(huán)境，一套是5.5，一套是5.6，為了保險起見，5.6的mysql也保持了5.5的原有配置，沒有開gtid.重啟的過程實在沒有技術(shù)含量，但是重啟之后從數(shù)據(jù)庫日志中出現(xiàn)了一些告警，告警信息如下：

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的參數(shù)設(shè)置影響，是否是5.6中的bug，因為有問題的是5.6的mysql服務器。

很顯然不是，因為5.6的配置我沒有修改其它的參數(shù)，只是開啟了binlog,原有的配置為了保險起見都沒有做變更。兩套環(huán)境的變更情況都是一樣。

對比場景2：是不是5.6的環(huán)境重啟的時候出了問題。

這個也可以排除，因為兩臺服務器都是做重啟，另外一臺服務器就沒有類似的問題。

對比場景3：對于這個問題，是否需要從應用端來查看是否有長連接未釋放的情況

這個也進行了排查，在應用端來看，沒有發(fā)現(xiàn)相關(guān)的問題，而且涉及環(huán)境著實很多。

對比場景4：最近存在一些網(wǎng)絡的變更，是否和dns的變更有一定的影響

對這個也求助了系統(tǒng)組進行協(xié)助，但是沒找到什么相關(guān)的日志。

對比場景5：重啟前和重啟后進行對比。

重啟前和重啟之后的日志信息是否有大的出入，當時查看error.log的時候看到報出了好幾頁的告警信息，也就沒有再往前翻更多的，看了4,5頁都是告警信息，哪想到查看之前的日志，發(fā)現(xiàn)以前也有類似的問題。

所以這種對比，有一個基準，和其它的環(huán)境做對比，可能也會得出一些相關(guān)的結(jié)論，但是當前環(huán)境的重啟前后做對比更能體現(xiàn)出問題的根源，如果之前就存在此類的問題，那就說明這是個歷史遺留問題，這些應用已經(jīng)可以停止嘗試連接了。

MySQL導入dump

前端時間做幾套基于云服務器下的MySQL數(shù)據(jù)遷移，碰到了幾個問題，當時還比較困擾我。

因為數(shù)據(jù)量不大，所以就采用了mysqldump做了邏輯導出，然后直接在目標環(huán)境邏輯導入。因為是新環(huán)境，所以有些庫導入沒有任何問題，有一個庫總是在導入的時候會自動退出。

報錯內(nèi)容為:

ERROR 2013 (HY000) at line 8441: Lost connection to MySQL server during query

當然對于這個問題，用了一下幾個對比場景來嘗試。

首先環(huán)境的內(nèi)存是16g，存在3個dump,分別為10g,20g,30g，最開始為了省事，我就開啟了三個nohup的進程去并發(fā)導入，數(shù)據(jù)在不同的數(shù)據(jù)庫中。

場景1：? 并發(fā)導入3個dump，導入失敗

場景2：? 串行導入也報錯，接著使用串行的方式導入，依舊失敗，因為自己也是稍后查看的日志，發(fā)現(xiàn)導入失敗，不確定全部都順利完成。

場景3：? 當然還在聯(lián)調(diào)階段，所以我還有一些時間來多做一些測試，然后導入20G，發(fā)現(xiàn)依舊失敗。

場景4：按照對比的思路，30g肯定也是導入不了，確實導入不了，不過發(fā)現(xiàn)30g的dump中在某一個表分區(qū)時導入就會失敗

場景5：嘗試對30g的dump中的這個分區(qū)表單獨導入，發(fā)現(xiàn)依舊存在問題。不過所幸開始查看日志，發(fā)現(xiàn)原來是 oom-killer導致， 這個和剩余內(nèi)存少密切相關(guān)，當然也和swap相關(guān)。

場景6：發(fā)現(xiàn)這些云服務器都沒有配置swap，添加了swap之后，? 導入10g的dump，就成功了。

場景7： 導入20g,也成功了，但是swap使用率在10g左右，swap配置了16G,為什么在10g左右徘徊呢，這個和swap的默認配置使用率有關(guān)，默認是60%，也就是9.6G左右，和現(xiàn)象中的10g是一致的。那么為什么會消耗大量的swap呢，初步懷疑是因為在線導入，因為業(yè)務上開始做聯(lián)調(diào)了，不能夠停應用，所以就出現(xiàn)了在線導入數(shù)據(jù)的情況。

場景8：那么接著導入30g的dump,是否依舊成功呢，遺憾的是這次還是失敗了， 因為發(fā)生了oom-killer，對應的線程被終止了，swap徹底釋放,swap使用量一下子重置為5M了。

場景9： 這個時候再次嘗試導入30g的dump,就沒有問題了，不過因為在線導入，會有一些鎖等待，而且對于資源的消耗著實夠高，swap使用率到了10G左右

場景10: dump已經(jīng)導入成功，為什么swap沒有釋放呢，一種方式就是重新掛載swap分區(qū)，但是讓人郁悶的是還是因為內(nèi)存不足。報出了下面的錯誤。

#swapoff -a

swapoff: /home/swapfile: swapoff failed: Cannot allocate memory

那么這種情況改怎么辦，目前來看重啟是一個唯一奏效的方案了。聯(lián)系應用重啟，但是一直沒協(xié)調(diào)下來，所以就這樣耽誤了幾天。

場景11：過了幾天之后我再次查看，發(fā)現(xiàn)swap已經(jīng)自動重置了，而重置的原因還是oom-killer，看來應該是有個連接被強制終止之后，觸發(fā)了oom-killer,然后swap徹底釋放。

那么這么多看起來瑣碎的場景，有個問題就是為什么內(nèi)存總是不足呢，除了swap還應該有些原因吧，最后發(fā)現(xiàn)還有一個原因就在于buffer_pool_size設(shè)置過大，本來16g的內(nèi)存，結(jié)果buffer_pool_size竟然設(shè)置了24G，為什么會出現(xiàn)這種低級錯誤呢，追根溯源發(fā)現(xiàn)原來使用的模板只校驗redhat,沒有校驗centos，而這臺服務器上安裝的恰恰是centos，所以在初始化參數(shù)的時候給直接設(shè)置了成了24G,所以這個模板也存在一些問題，本身的校驗邏輯還是不夠嚴謹。

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

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。