個人服務器遷移踩坑經驗分享

去年年末由於使用了雲存儲和其餘方面的緣由，計劃的將服務器縮減一個機櫃出來。這樣今年每個月機房的費用能夠減小1萬左右。前先後後抽空在弄這個任務，現作個筆記小結下。以redis服務和圖片存儲服務器的下架爲主。

Redis 的遷移

原來一些機器的配置比較低，Redis 服務器比較多。去年新增的幾臺服務器都是128G，因此須要將原來的服務器集中存放到新服務器上。redis 數據庫的遷移，也還算輕車熟路了。https://mengkang.net/424.html 數據同步完畢以後，再到業務代碼中修改請求地址。
注意事項：
將啓動命令添加到/etc/rc.local中。
遷移前一段時間須要觀察監控舊服務器的確是沒有請求了，能夠經過netstat配合tcpdump一塊兒。好比遷移的時192.169.50.138的6307的業務。能夠在138服務器上經過

netstat -anc|grep "138:6307"

查看是否有請求，可是發現這個命令有時候不許，同時能夠直接經過tcpdump直接監控網卡的流量

tcpdump  -i em2 -vv -nn host  192.168.50.138 and  port 6307

最好是收集必定週期的日誌，後期我就發現gearman的業務的遺漏。

圖片存儲的重構

由於使用了網宿的雲存儲，大部分的回源壓力都是指向雲存儲的，而咱們源站只是作覺得一個備份，原來由於單機 I/O 壓力過大和防止硬盤損壞，機房有4臺磁盤陣列做爲主要存儲，本部分區存在冗餘，如今下架三臺。須要作的工做是將圖片資源經過rsync同步到一臺服務器上，而後在前端主機nginx配置回源的域名和對應的目錄。（仍是有遺漏，部分用戶頭像被咱們直接搬回公司了，經過rsync從公司回傳到機房了，能夠經過--bwlimit參數限速。經過iptraf -g來查看帶寬使用狀況。）

Crontab 的檢查

好比上面說的gearman的業務，通常守護進程都在crontab都會有監控的shell腳本。注意該服務的搬遷時，該服務的搬遷。有些服務可能一時半會沒搬遷不會顯露出問題，好比周報、月報數據，可能下個月才發現。
同時，因爲gearman worker程序是在我遷移redis以前就以守護進程的形式常駐內存了，當我修改完各個redis服務的請求地址時，gearman worker的程序實際還沒更新的，因此出現了上面說的老服務器還有請求的狀況。同理這些和遷移的redis有關的守護程序，重啓下。

架構體系的更新

因爲咱們各個服務器都並不是單一職能的，因此可能用做其餘業務。好比一臺redis服務器多是keepalived的backup。那麼須要新找一臺服務器添加爲backup，同時涉及到新nginx環境的搭建，配置，舊的負載均衡服務器的配置修改（後端服務器ip，圖片資源回源請求地址等）。相似的還有php,java的配置等。
雲服務的回源 web 服務器的配置（中間漏了一臺，後期給補上了）。
同時，代碼上下、分發腳本，服務批量重啓腳本，也須要配合一塊兒修改。

關機重啓

由於下架的機器分佈在多個機櫃，如今要騰出來一個機櫃，那麼有的機器就須要斷電了，（比較暴力，見笑了。）因此須要以前要檢查各個服務器的/etc/rc.local文件，確保應該自啓動的服務都已經添加了，其餘初始化的配置也都正常。注意 Redis 緩存數據的保存和恢復。

監控

遷移完畢以後，除了常規的業務代碼，還須要注意圖片資源的回源是否正常、服務器 I/O 壓力是否正常、檢查nginx日誌是否出現502,500,404錯誤。

沒看夠 最近老鐵開了直播，歡迎來捧場！

• PHP 進階之路 - 億級 pv 網站架構的技術細節與套路

• PHP 進階之路 - 億級 pv 網站架構實戰之性能壓榨

• PHP 進階之路 - 後端多元化之快速切入 Java 開發