有了自知之明才能做對的事情，得益於老客戶的信賴和我們過去幾年實踐經驗的積累，今天終於算是完成了一個大型任務。
前幾天我們的客戶遇到了一個大問題，因為具體細節有關隱私和安全防護，就不多介紹，主要是去年到今年我們給部署了五臺 WordPress 多站點站群伺服器的老客戶突然全部網站系統發生異常，訪問慢或者 502 錯誤、後臺打不開，原因是這幾臺伺服器都共用的一臺 RDS 資料庫伺服器 （阿里雲），也就是客戶開啟和建立的子站太多，每臺機器差不多有 1~2000 個站，而且都是活動和動態更新的網站。
突然就出現了伺服器無法正常訪問或者很慢間歇性的故障，檢查了下 RDS 資料庫用量，發現純資料庫的大小已經超過了 100 多 GB ，而且 CPU 已經是 97% 以上，快要爆表了。
要解決此問題有兩種方式，一種是升級阿里雲的 RDS 資料庫提高效能，另一種就是新購一臺資料庫伺服器，然後將五個 WordPress 多站點站群的資料庫給切割分離，這些操作並不是最麻煩的，真正的麻煩是阿里雲對資料庫做了一大堆的限制，連正常的資料表匯出都沒辦法實現，每次只能匯出 100 張表，但現在資料庫裡面有超過 8 萬張資料表。
看了下阿里雲的 RDS 企業版說明，升級後最多可以一次匯出 10GB 的資料，這樣的話也是很雞肋，因為五個 WordPress 系統的資料庫加起來是 100 多 GB ，這樣的話即使一次匯出 10 GB，也都得十次才能匯出完，另外匯出後還需要下載，再次上傳。。。這麼操作起來，起碼得一週左右的時間跨度才能把這些資料處理完。
花了一個早上，我們制定了一個方案，確切的說是換了種思路，還是想辦法從 WordPress 系統本身也就是 Web 程式端入手。
既然阿里雲限制不允許進行大批次的操作，那麼換種方式，我們直接從 WordPress 站群系統裡先 「匯出」 一個包含全部子站資料庫表的完整備份不就行了。這樣的話，我們只需遷移的舊伺服器的資料庫備份，然後再去新資料庫裡恢復。
操作步驟也公佈下：
1 、進入 WordPress 多站點站群，匯出全部子站的資料庫，保留好備份 （A），再對全站的靜態資料和系統檔案進行備份；
2 、調配好新的資料庫，然後刪掉/修改 WordPress 多站點站群的配置檔案，再用新庫 （B） 的資訊進行安裝，也就是程式再全新部署一次；
3 、將備份資料庫檔案進行恢復處理，這樣就可將舊站 （A） 的資料全部都恢復到新的資料庫 （B），而且保留了原始檔案和網站結構；
上面的三個步驟看上去很簡單，但對於一個單就資料庫超過 100 GB 的專案來說，並不容易，因為本身系統的資源就已經不夠了，我們採取的策略是備份某一臺伺服器資料庫的時候先對其他幾臺進行停機處理。
舊庫備份成功後，再到新庫 （B） 裡面建立一個資訊與舊庫 （A） 一樣的資料庫，然後手動將站群程式再使用新的資料庫資訊部署一遍，這樣就不再使用舊庫 （A） 裡面的資料表，但新庫 （B） 裡面目前還是空白的，後面透過 Web 端的 WordPress 程式恢復原先備份的舊庫 （A），等待資料匯入完成後，也就遷移搬家完成了。
經過反覆測試了整整三天的時間 （白天晚上都在試），我們完成了對資料庫的分離和遷移，也就是將其中的三臺 WordPress 站群伺服器給遷到了新庫中，整體的資料量加起來差不多有 3000 多個站點，而原先的舊資料庫也得以減負了幾十 GB ，現在各個站點都已經恢復正常可用。
這是我們做的最大規模的一次資料遷移和資料庫分離，五臺伺服器全部的子站加起來有 5000 多個 WordPress 站點，然後分離後成功遷移差不多 3000 多個 WordPress 站點。
除了我們對站群系統的效能最佳化外，WordPress 系統本身良好的資料結構和可擴充套件性也是不可忽視的因素。
總體來說，這個資料遷移訂單處理的沒那麼輕鬆，但也不是很棘手，更重要的應該是此次的折騰操作讓薇曉朵具備了處理 TB 級別 WordPress 大資料的能力 （1TB=1024GB），也對大型資料庫的處理有了更深入瞭解。
同時這也為我們後續的 WordPress 多叢集和多租戶系統解決方案有了一次測試和實踐的機會，未來我們想在一天之內就可以轉移和遷移 10000 個 WordPress 網站，雖然現在一般站群客戶都是隻有開 2000~3000 個站的，但越往後發展，我們可以做和能做的事就會越多。
發表回覆