公司的生產資料庫原本只跑在馬來西亞的 Kubernetes 叢集裡,而且只有一份。主管問「如果 Azure 整區掛掉怎麼辦」,於是有了這個專案。
這 30 篇記錄一次真實的混合雲災害復原建置:把生產資料庫從馬來西亞遷到日本的 Azure MySQL,再透過 IPsec 隧道複製回台灣的地端機房,讓雲端出事時能切回自己的機器。內容包含方案取捨、網段規劃、複製建立、定序統一、故障演練與正式切換,以及最後實測到的 12 分鐘 RTO。
我任職一年多、非本科出身,這是第一次獨立負責這種規模的事。所以文章裡除了怎麼做,也有走錯的路、誤判的訊號,和事後才明白當初那個決定為什麼重要。
昨天講的那個 DNS 的坑,發生在測試環境。而同樣的坑在生產環境不可能發生,因為兩邊的網路根本不是同一種設計。 同一套架構,為什麼要做兩種? 環境之間不是應該盡...
前面 11 篇講的都是資料庫。但這次遷移要搬的東西,有一部分根本不在資料庫裡。 我們的產品會發布韌體更新,使用者的耳機透過 App 下載新版本。那些韌體檔案是實...
建置篇結束,網路通了、資料庫也建好了。接下來要把資料搬過去。 我在這件事上用了兩種完全不同的做法。測試環境(7 月)用第一種,生產環境(8 月)換成第二種。 換...
昨天說到生產環境的做法是「服務先建結構、我們只灌資料」。今天講倒資料那一步。 原本我以為這步很單純:一個指令把資料倒出來,另一個指令灌進去。實際上中間要做的事比...