發(fā)布日期：2017/7/26

摘要： 筆者有個網(wǎng)站因舊服務器出了點問題，需要遷移到新的服務器上，整個過程可謂是一波三折，那如何避免踩坑呢，筆者通過自己的一些經驗分享給大家，希望大家在類似的問題上得以解

 

　　筆者有個網(wǎng)站因舊服務器出了點問題，需要遷移到新的服務器上，整個過程可謂是一波三折，那如何避免踩坑呢，筆者通過自己的一些經驗分享給大家，希望大家在類似的問題上得以解決，少走彎路。

　　一、選用空間商

　　前期預備選用西部數(shù)碼的虛擬空間，上傳代碼和數(shù)據(jù)庫花費不少時間，效果發(fā)現(xiàn)綁定域名數(shù)量有限，且域名不能映射到指定的目錄，在數(shù)據(jù)同步這一塊有許多，左思右想照舊選擇國外比較好的空間商godaddy。

　　二、數(shù)據(jù)導入

　　fa68的數(shù)據(jù)有將近達到一個G，雖然godaddy的phpmyadmin提供了可上傳1G的文件，但考慮到網(wǎng)頁上傳速度太慢，且有可能網(wǎng)絡中止，然后通過遠程客戶端native連接的體例導入執(zhí)行sql，通過一個多小時的導入過程，發(fā)現(xiàn)native提醒300多條錯誤，只有部分表導入成功，提醒錯誤為MySQL server has gone away，可能是DB連接超時，以及數(shù)據(jù)導出的mysql版本和導入的版本有沖突，所以被迫取消這種體例。無意中在Godaddy cPanel上看到SSH功能，那就好辦了，登錄舊服務器通過SCP飭令將文件遠程同步到現(xiàn)在新的服務器上，其實到這一步剩下的事情應該是很簡單了，但我鬼使神差的使用了mysqldump飭令去導入sql文件到數(shù)據(jù)庫(如：mysqldump -uusername -ppwd -hlocalhost -P3306 fa68 < fa68_20140906.sql 導入)，效果每次執(zhí)行都已失敗告終，查閱了資料才發(fā)現(xiàn)飭令使用錯誤，正常導入sql文件的飭令是：mysql -uusename -ppwd -hlocalhost -P3306 fa68 < fa68_20140906.sql，多么低級的錯誤，連我自己都不能饒恕自己了。

　　三、URL重寫

　　因為在購買之前是確認過godaddy支撐rewrite功能，原本以為只要代碼上傳上去，修改下某些配置，就能跑起來了，但世事難料，訪問偽靜態(tài)頁面的時候報：No input file specified，也就是404錯誤頁面，通過各種方法排查出：是godaddy php沒有識別出pathinfo導致的，因為godaddy使用的是Fastcgi模式，php不支撐目標網(wǎng)址的pathinfo解析，既然找到問題那就好辦了，修改網(wǎng)址根目錄下的.htaccess文件中的這句 RewriteRule ^(.*)$ index.php/$1 [QSA,PT,L] 改為 RewriteRule ^(.*)$ index.php?s=$1 [QSA,PT,L]，到此完美解決網(wǎng)站訪問問題。

　　四、服務器配置

　　因前期沒有對網(wǎng)站訪問統(tǒng)計數(shù)據(jù)進行過分析評估，買的godaddy配置是Resource Level 1，是基本的配置了，配置也許如下：CPU 1個、Physical Memory 512M、進程100個，效果網(wǎng)站一上線，導致大量的php crash，php主進程重啟，CPU達到100%，內存崩潰，導致新注冊用戶、發(fā)的廣告信息數(shù)據(jù)大量丟失，一看QQ已經有許多頭像在閃動，知道為什么許多嗎?因為悉數(shù)都是網(wǎng)站用戶來投訴了，后臺監(jiān)控中間告急，配置升級到Resource Level 2，各種配置參數(shù)翻倍，該問題得到解決。

　　自己總結分析了下，這次遷移碰到的各種問題，我覺得是前期考慮不周全，比如空間商選擇、對godaddy產品不夠了解，沒有對網(wǎng)站需要的配置有一個現(xiàn)實的評估，也沒去分析可能會碰到的風險點，沒有制訂任何回滾措施，就這樣糊涂的上線了，效果導致大量用戶投訴反饋，用戶體驗極度不好。通過這次遷移事件總結：做一件事情，行動之前一定要三思，要對這個事情一定要有個通盤的了解，對每個涉及的環(huán)節(jié)由表及里的去分析，等你把整個事情設計好后，你會發(fā)現(xiàn)接下來的事情是如此的順利、簡單、完美，總之細節(jié)和態(tài)度決定成敗!