公司運營項目遷移，這個項目最重要的就是充值和讓玩家能玩游戲，還有后臺統計，就是類似支付寶這樣的第三方平臺的支付工具，由于涉及的到錢，所以上個月就做好遷移的準備，將代碼和數據庫都已轉移完畢，并提交運營那邊測試，***跟運營討論說凌晨0點充值的人最少，開始切域名，考慮到切換DNS后無法立即生效，所以做了301跳轉，整個遷移流程是:

1.暫停原服務器數據庫，導出相關數據庫

2.將導出的數據庫同步到杭州xx服務器上面并導入到數據庫中

3.切換域名指向到xx服務器

4.原服務器上面做301跳轉到xx服務器（保證不寫入新數據到原運營服務器上面）

5.運營協助測試新服務器數據是否正常

按照上面的流程操作，結果出現了很多意想不到的問題，因為這次遷移的LNMP環境不同，特別的是數據庫，以前用的是Ver 14.14 Distrib 5.1.60，新服務器用的是Ver 14.14 Distrib 5.6.16，還有一個mysql的主輔同步，做了過濾，只同步了某些表，當時凌晨遷移，將***的數據再次導入新服務器mysql，由于版本的問題，發現有個mysql存儲過程無法導入，還有默認值問題，如下圖:默認值要改為"NULL"，不能是"無"，原mysql中還有些定時任務無法導出，只能重新創建了。

好了，解決了上面的問題，重新做了mysql主輔同步和過濾，當時測試也是正常的，結果第二天早上8點半用戶流量過來了，網站都打不開了，首先查看了php日志，出現下面這個問題：

然后不斷的修改下面的參數，感覺調到2048后已經是臨界值了，因為這臺機器只有8G內存，max_children = 2048后發現內存基本滿了，在調高可能內存就爆了，當時調整php后發現可以短時間的正常訪問，功能也正常，但是過了10分鐘左右，又出現訪問很慢的問題，繼續看php日志，還是上圖的提示，感覺這個不是php的問題，因為這個網站原服務器沒有開啟這么多php進程，但是運行正常，整個站的出口流量也不大。

綜上分析，發現應該是php連接mysql出現了堵塞，導致php進程一直在排隊，當新的請求過來后，由于其他的php進程都在排隊，只能在開啟新的php進程，php進程永遠提示繁忙，不夠用，要調整max_children值，于是就看mysql是不是有問題？

進mysql，show processlist查看mysql的全部的線程，發現pay庫里面有張uc_members表大量lock，

大量的鎖表，詢問開發這張表是用戶表，也就是用戶每次登錄都要查詢這張表，這下終于找到原因了，就是php執行用戶登錄的時候，要讀取mysql中這張uc_members表，每個用戶登錄都要鎖表然后查詢用戶登錄信息，導致這張表一直處于被鎖死的狀態，隨著用戶請求越來越多，php進程也增多，一直等待mysql返回用戶登錄信息，但是mysql一直處于鎖表狀態，結果就導致了這種現象，php進程卡死，用戶無法登錄，網站***也打不開。

查看這張表用的是MyISAM的引擎:

MyISAM引擎是表級鎖，更換為InnoDB引擎為行級鎖，再次show processlist發現鎖表大量減少，頁面可以正常打開，用戶也可以登錄了，問題解決。

InnoDB與Myisam的六大區別：

參考：http://www.ha97.com/4197.html
 

總結:

已經建議開發部門，以后開發程序不要再mysql里面寫定時任務，因為mysql里面寫定時任務，執行成功與否很難看到，遷移mysql的時候也會很麻煩，可以寫crontab讓php去執行定時任務即可，還有存儲過程，如果一定需要在mysql里面寫存儲過程，盡量要規范，防止以后遷移由于mysql版本問題導致很多奇怪的現象。

出現這次故障主要是事先沒有做壓力測試，只是做了網站基本功能的測試，下次遷移網站之前一定要做好壓力測試，用戶登錄測試及回滾方案，一個完整的遷移流程應該是:

1.暫停原服務器數據庫，導出相關數據庫

2.將導出的數據庫同步到杭州xx服務器上面并導入到數據庫中

3.對xx服務器進行壓力測試及用戶登錄測試

4.回滾方案，出現問題及時回滾到原服務器，保證用戶正常訪問

5.切換域名指向到xx服務器

6.原服務器上面做301跳轉到xx服務器（保證不寫入新數據到原運營服務器上面）

7.運營協助測試新服務器數據是否正常