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

1.暫停原服務(wù)器數(shù)據(jù)庫，導(dǎo)出相關(guān)數(shù)據(jù)庫

2.將導(dǎo)出的數(shù)據(jù)庫同步到杭州xx服務(wù)器上面并導(dǎo)入到數(shù)據(jù)庫中

3.切換域名指向到xx服務(wù)器

4.原服務(wù)器上面做301跳轉(zhuǎn)到xx服務(wù)器（保證不寫入新數(shù)據(jù)到原運(yùn)營(yíng)服務(wù)器上面）

5.運(yùn)營(yíng)協(xié)助測(cè)試新服務(wù)器數(shù)據(jù)是否正常

按照上面的流程操作，結(jié)果出現(xiàn)了很多意想不到的問題，因?yàn)檫@次遷移的LNMP環(huán)境不同，特別的是數(shù)據(jù)庫，以前用的是Ver 14.14 Distrib 5.1.60，新服務(wù)器用的是Ver 14.14 Distrib 5.6.16，還有一個(gè)mysql的主輔同步，做了過濾，只同步了某些表，當(dāng)時(shí)凌晨遷移，將***的數(shù)據(jù)再次導(dǎo)入新服務(wù)器mysql，由于版本的問題，發(fā)現(xiàn)有個(gè)mysql存儲(chǔ)過程無法導(dǎo)入，還有默認(rèn)值問題，如下圖:默認(rèn)值要改為"NULL"，不能是"無"，原mysql中還有些定時(shí)任務(wù)無法導(dǎo)出，只能重新創(chuàng)建了。

好了，解決了上面的問題，重新做了mysql主輔同步和過濾，當(dāng)時(shí)測(cè)試也是正常的，結(jié)果第二天早上8點(diǎn)半用戶流量過來了，網(wǎng)站都打不開了，首先查看了php日志，出現(xiàn)下面這個(gè)問題：

然后不斷的修改下面的參數(shù)，感覺調(diào)到2048后已經(jīng)是臨界值了，因?yàn)檫@臺(tái)機(jī)器只有8G內(nèi)存，max_children = 2048后發(fā)現(xiàn)內(nèi)存基本滿了，在調(diào)高可能內(nèi)存就爆了，當(dāng)時(shí)調(diào)整php后發(fā)現(xiàn)可以短時(shí)間的正常訪問，功能也正常，但是過了10分鐘左右，又出現(xiàn)訪問很慢的問題，繼續(xù)看php日志，還是上圖的提示，感覺這個(gè)不是php的問題，因?yàn)檫@個(gè)網(wǎng)站原服務(wù)器沒有開啟這么多php進(jìn)程，但是運(yùn)行正常，整個(gè)站的出口流量也不大。

綜上分析，發(fā)現(xiàn)應(yīng)該是php連接mysql出現(xiàn)了堵塞，導(dǎo)致php進(jìn)程一直在排隊(duì)，當(dāng)新的請(qǐng)求過來后，由于其他的php進(jìn)程都在排隊(duì)，只能在開啟新的php進(jìn)程，php進(jìn)程永遠(yuǎn)提示繁忙，不夠用，要調(diào)整max_children值，于是就看mysql是不是有問題？

進(jìn)mysql，show processlist查看mysql的全部的線程，發(fā)現(xiàn)pay庫里面有張uc_members表大量lock，

大量的鎖表，詢問開發(fā)這張表是用戶表，也就是用戶每次登錄都要查詢這張表，這下終于找到原因了，就是php執(zhí)行用戶登錄的時(shí)候，要讀取mysql中這張uc_members表，每個(gè)用戶登錄都要鎖表然后查詢用戶登錄信息，導(dǎo)致這張表一直處于被鎖死的狀態(tài)，隨著用戶請(qǐng)求越來越多，php進(jìn)程也增多，一直等待mysql返回用戶登錄信息，但是mysql一直處于鎖表狀態(tài)，結(jié)果就導(dǎo)致了這種現(xiàn)象，php進(jìn)程卡死，用戶無法登錄，網(wǎng)站***也打不開。

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

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

InnoDB與Myisam的六大區(qū)別：

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

總結(jié):

已經(jīng)建議開發(fā)部門，以后開發(fā)程序不要再mysql里面寫定時(shí)任務(wù)，因?yàn)閙ysql里面寫定時(shí)任務(wù)，執(zhí)行成功與否很難看到，遷移mysql的時(shí)候也會(huì)很麻煩，可以寫crontab讓php去執(zhí)行定時(shí)任務(wù)即可，還有存儲(chǔ)過程，如果一定需要在mysql里面寫存儲(chǔ)過程，盡量要規(guī)范，防止以后遷移由于mysql版本問題導(dǎo)致很多奇怪的現(xiàn)象。

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

1.暫停原服務(wù)器數(shù)據(jù)庫，導(dǎo)出相關(guān)數(shù)據(jù)庫

2.將導(dǎo)出的數(shù)據(jù)庫同步到杭州xx服務(wù)器上面并導(dǎo)入到數(shù)據(jù)庫中

3.對(duì)xx服務(wù)器進(jìn)行壓力測(cè)試及用戶登錄測(cè)試

4.回滾方案，出現(xiàn)問題及時(shí)回滾到原服務(wù)器，保證用戶正常訪問

5.切換域名指向到xx服務(wù)器

6.原服務(wù)器上面做301跳轉(zhuǎn)到xx服務(wù)器（保證不寫入新數(shù)據(jù)到原運(yùn)營(yíng)服務(wù)器上面）

7.運(yùn)營(yíng)協(xié)助測(cè)試新服務(wù)器數(shù)據(jù)是否正常