不停機把 VPS 遷移到新服務供應商

每個遷移翻車的故事，中間情節都一樣：有人先改了 DNS，然後才開始複製資料。遷移時的停機幾乎從來不是因為複製太慢，而是因為步驟順序錯了。

下面是行得通的順序，不管您是從別的服務供應商遷過來，還是在我們的兩個方案之間遷移。

1. 提前兩天：調低 TTL

找到您要修改的 DNS 記錄（通常是 A、AAAA，以及指向它們的 CNAME），把 TTL 調到 300 秒。然後至少等待舊 TTL 那麼長的時間。TTL 為一天的記錄，意味著修改後部分解析器還會繼續返回舊位址一整天，您在伺服器上做什麼都無法加快這一過程。

這是大家最常跳過的一步，也正是它把五分鐘的切換變成了一整天：一半使用者看到的仍是舊伺服器。

2. 給舊伺服器做一份清單

您要在別處重建這台機器，所以把它實際在做的事情寫下來。不是您記得的，而是它真正在做的：

ss -tlnp                                # what is listening, and which process
crontab -l; ls /etc/cron.d              # scheduled jobs
systemctl list-timers --all             # the scheduled jobs people forget
systemctl list-units --type=service --state=running

再補充進清單：TLS 憑證及其續期方式、存放金鑰的環境變數檔案、防火牆規則、使用者和他們的 SSH 金鑰、資料庫及其大小，以及所有透過 IP 位址存取這台伺服器的東西。最後這一類最容易被忽略：合作方的白名單、支付服務供應商的 Webhook 設定、某個監控檢查。

3. 在舊伺服器旁邊搭建新伺服器

訂購新伺服器，舊的先別動。從 VPS 列表 裡選一個磁碟不小於您實際用量的方案，而不是當初賣給您的容量。如果舊機器接收任何對內流量（網站、Webhook、API），新機器就需要獨立 IPv4。NAT 方案只在 SSH 埠上接受對內連線，一個轉發埠能做什麼、不能做什麼 解釋了為什麼這一點很重要。

連上去，安裝同樣的套件，重新建立使用者和防火牆。金鑰和首次登入見 連線指南。

4. 同步兩次檔案

第一次同步在舊伺服器照常執行時複製全部內容。可能要好幾個小時，沒關係。

rsync -aHAX --numeric-ids --info=progress2 /var/www/ root@203.0.113.10:/var/www/

--numeric-ids 按數字保留檔案屬主，避免了兩套系統使用者建立順序不同時那種經典的「所有檔案都屬於錯誤使用者」的意外。如果您沒用過基於 SSH 的 rsync，如何把檔案傳到 VPS 會一步步講清楚。

第二次同步在切換前進行，只複製第一次之後有變化的部分，通常幾秒鐘就完成。

5. 慎重地遷移資料庫

檔案很簡單。接收寫入的資料庫是唯一一個「不停機」需要要麼做點小妥協、要麼多花功夫的地方。

簡單的辦法：先匯出、匯入一次用於測試；切換時停寫一分鐘（把應用設為唯讀或停掉），重新匯出一份，匯入到新伺服器，然後在新伺服器上啟動應用。對大多數小專案來說，這就是一兩分鐘的停頓，可以提前通知。

不停頓的辦法：設定從舊資料庫到新資料庫的複製，等它追上進度，切換時把新庫提升為主庫。設定更多，但當哪怕一分鐘的寫入遺失都無法接受時，這是值得的。

6. 在別人看到之前測試新伺服器

DNS 仍然指向舊伺服器，所以您可以私下測試新伺服器。把對真實網域的請求發到新位址：

curl --resolve example.com:443:203.0.113.10 https://example.com/health

如果憑證還沒配好，就用同樣的方式走 HTTP 測試，或者在 hosts 檔案裡臨時加一行，在瀏覽器裡把網站點一遍。檢查登入、上傳、背景任務和外發郵件。這是發現缺少某個 PHP 擴充成本最低的時刻。

7. 切換，並讓舊伺服器繼續執行

完成最後一次檔案同步和資料庫步驟，然後修改 DNS 記錄。TTL 為 300 秒時，大部分流量幾分鐘內就會轉過去。盯著舊伺服器的存取記錄：那些忽略 TTL 的解析器和用戶端還會零星地發來請求。讓它保持原樣執行幾天。之後更新所有指向舊 IP 的地方：合作方白名單、Webhook 位址，以及郵件相關的新位址反向 DNS（在我們的獨立 IP 方案上可以自己設定，見 反向 DNS）和 SPF 記錄。

最常出問題的地方

大致按我們見到的頻率排序：沒人列進清單的 systemd 定時器、寫死舊 IP 的設定檔案、屬於錯誤使用者的檔案、擋住應用自身埠的防火牆、在舊伺服器上續期而新伺服器上沒續期的憑證，以及因為新位址還沒有反向 DNS 而被扔進垃圾箱的郵件。

這份清單不適用的情況

寫入持續不斷、完全不能停頓的繁忙資料庫，需要的是正經的複製方案和一次彩排，而不是一篇部落格清單。Windows 伺服器的遷移工具和 rsync 不同。另外，如果遷移的真正原因是設定不夠用，先看這一點：這裡的方案可以原地升級。升級到同一網路型別的更大方案，只需重新啟動一次就能增加 vCPU、記憶體和磁碟，完全不用遷移。只有降配才需要新伺服器。如果您是因為不確定機器夠不夠用才想遷移，什麼時候真的需要 64 GB 記憶體 也許能幫您省掉這趟折騰；如果您還不確定 VPS 是否適合您，可以看看 VPS、共享主機、獨立伺服器和雲平台的比較。