GCP 數據庫怎麼平滑遷移? 利用 Database Migration Service (DMS) 實現不停機遷移
在雲計算的領域裡,有一件事能讓所有架構師和運維(SRE)通宵加班、提心吊膽,那就是
數據庫遷移
。
很多人一聽到「遷庫」,腦海里浮現的畫面就是:挑一個大年三十或者凌晨三點的業務低峰期,掛起首頁公告「系統維護中」,然後急急忙忙地導出 SQL、傳輸文件、導入新庫、修改配置…… 整個過程如同高空走鋼絲,一旦中間哪個環節卡住或者數據對不上,業務停服時間就會無限拉長。
但實際上,現在的雲廠商早就不流行這種「殺敵一千,自損八百」的硬核搬家方式了。 今天我們就來聊聊谷歌雲(GCP)提供的一款神器--
Database Migration Service (DMS)
。
作為在生產環境滾過滿身泥的過來人,我今天用最通俗易懂的語言,不扯官方文檔那些讓人昏昏欲睡的術語,手把手教你如何利用 DMS 實現「零停機(Minimal Downtime)」的平滑搬家。
一、 核心概念:什麼是 DMS 的「零停機搬家」?
在動手之前,我們先花一分鐘搞明白它的底層邏輯。 DMS 之所以能做到「零停機」,核心在於它不是一次性把數據扔過去,而是分成了兩個階段:
谷歌雲賬號購買
全量初始化(存量數據複製):DMS 會先把源數據庫里現有的所有歷史數據,完整地複製到 GCP 的目標庫(比如 Cloud SQL)中。 在這個過程中,你的線上業務照常運行,正常的讀寫完全不受影響。
增量同步(實時追數據):當歷史數據傳完後,DMS 會通過讀取源庫的日誌(比如 MySQL 的 Binlog 或 PostgreSQL 的 WAL),把全量搬家期間新產生的業務數據,源源不斷地「同步」到新庫中。 這時候,新舊兩個庫的數據幾乎是完全實時同步的。
由於新舊庫數據保持一致,你可以在大白天、業務最清閒的時候,優哉遊哉地把應用程序的數據庫連接字符串(connection String)改成新庫的地址。
業務中斷時間僅僅是重啟應用、切換配置的那幾十秒,甚至幾秒鐘。
二、 搬家前的「三道安檢」(準備工作)
用 DMS 搬家就像坐飛機,安檢做好了,航行就成功了一半。 以下三點直接決定了遷移會不會失敗:
1. 開啟源庫的日誌(最關鍵的一步)
DMS 必須要能讀取你源庫的實時日誌,才能做增量同步。
如果源庫是 MySQL:你必須確保開啟了 binlog,並且 binlog_format 必須設置為 ROW,binlog
_Row_image 設置為 FULL。
如果源庫是 PostgreSQL:你需要把 wal_level 設置為 logical,並配置好複製槽(Replication Slots)。
2. 想好網絡怎麼通(連通性方案)
源庫和 GCP 之間必須能安全地說話。 DMS 提供了幾種連接方式,按照安全和推薦程度排序:
VPC peering(VPC 對等連接):如果你的源庫已經在 GCP 的另一個 VPC 或者是通過專線(Interconnect)連通的機房,這是首選,速度快且安全。
Reverse SSH Tunnel(反向 SSH 隧道):最常用的平民方案。 在源庫的網路裡開一台小虛擬機作為跳板機,通過加密隧道讓 GCP 連進來。
IP 允許列表(Public IP):最簡單但也最不推薦。 直接把源庫的公網 IP 暴露給 DMS 的 IP 範圍。 如果只是測試可以這麼幹,生產環境慎用。
3. 創建遷移賬號
谷歌雲帳號購買
不要直接用
根
或
管理員
這種至高無上的賬號去跑遷移。 在源庫專門創建一個臨時的
Dms_user
,只給它賦予必要的讀取、複製權限(例如 MySQL 的
REPLICATION CLIENT
，
REPLICATION SLAVE
，
選擇
等)。 搬家結束後,直接把這個賬號刪掉,安全又優雅。
三、 實戰:DMS 配置四步走
準備工作做完,我們直接進入 GCP 控制台,搜索
Database Migration
。
第一步:創建「遷移作業(Migration Job)」
點擊創建後,你需要填入作業的基本信息:
源數據庫類型:比如自建的 MySQL、AWS RDS 或者是其他雲的數據庫。
目標數據庫類型:通常是 GCP 託管的 Cloud SQL 或 AlloyDB。
遷移類型:毫不猶豫選擇 「持續同步(Continuous)」。 只有選這個才是零停機搬家;如果選「一次性(One-time)」,那數據傳完就結束了,不包含後續的增量同步。
第二步:配置源連接(Connection Profile)
這裡就是把我們剛才準備的「安檢信息」填進去:
輸入源庫的 IP 地址、端口、剛才創建的 dms_user 賬號和密碼。
選擇你定好的網絡連通方式(比如配置好 Rev
Erse SSH 隧道)。
點擊「測試連接」,確保進度條變成綠色。 如果報錯,通常是防火牆或者安全組沒放行,回去檢查網絡。
第三步:配置目標庫(Cloud SQL)
如果目標 Cloud SQL 還沒創建,DMS 允許你直接在界面里「一鍵新建」。
你可以選擇與源庫一樣的配置(CPU、內存、存儲空間)。
強烈建議:在這裡順便把目標庫的高可用(HA)和自動備份勾選上,一步到位。
第四步:開始校驗併運行(Start Job)
點擊運行前,DMS 會有一個非常強大的「預檢查(Pre-flight check)」功能。 它會自動幫你檢查:源庫的日誌格式對不對? 權限夠不夠? 版本兼不兼容?
如果有紅色報錯,根據提示去源庫改配置;如果全是綠色勾,直接點擊
「開始(Start)」
。
四、 割接(Cutover):如何完美打響「最後一槍」
當作業運行起來後,你會看到狀態變成
Full dump in progress
(全量導出中),接著變成
CDC in progress
(增量同步中)。
當狀態進入
CDC in progress
且
「同步延遲(Lag)」趨近於 0
的時候,意味著新庫和舊庫的數據已經完全同步了。 這時候,我們就可以準備真正的「割接」了。
這裡是決定零停機成敗的精髓,請嚴格按照以下步驟操作:
1. 業務切向「只讀」
為了防止在切換連接的幾秒鐘內有新的數據寫錯地方,先在應用層或者源數據庫上,將業務設置為「只讀模式(Read-Only)」。
2. 等待 DMS 最後一波數據追平
觀察 DMS 界面,確保延遲(Lag)徹底變成 0。 這代表源庫在只讀前產生的最後幾條數據,已經穩穩地躺在 GCP 的新庫裡了。
3. 在 DMS 上點擊「完成(Promote)」
在 GCP 控制台點擊
「Promote」
按鈕。 這個動作會做兩件事:
斷開新庫與舊庫的同步關係。
谷歌雲帳號購買
把目標 Cloud SQL 從「只讀的接收方」提升為「完全可獨立讀寫的生產主庫」。
4. 修改應用配置,全量上線
把你們應用程序的數據庫連接配置,改成新 Cloud SQL 的 IP 地址,取消應用的只讀模式,重新啟動服務。
檢查業務,看看前台下單、後台登錄是否正常。 如果一切順利,恭喜你,這場驚心動魄的數據庫大搬家,在用
戶完全沒有感知的情況下,圓滿完成了!
五、 新手避坑與經驗談
雖然 DMS 很好用,但作為過來人,有幾個隱形大坑必須提醒你:
大錶缺少主鍵(Primary Key):如果你的源庫里有一些非常大的表,裡面居然沒有設主鍵,DMS 在做增量同步(CDC)時性能會極差,甚至可能導致同步卡死。 遷移前,務必讓開發同學把沒有主鍵的表補上主鍵。
網絡帶寬不要省:全量搬家階段非常消耗網絡帶寬。 如果你的源庫在本地機房,專線或者公網帶寬太小,不僅搬家會搬幾天幾夜,還可能把你們機房的正常業務帶寬給擠爆。 記得在業務低峰期啟動全量搬家,或者在 DMS 里設置流量限制。
注意時區(Timezone)問題:Cloud SQL 默認是 UTC 時區。 如果你的源庫是用的是 Asia/Shanghai(東八區),遷移後應用查出來的時間可能會莫名其妙少 8 個小時。 記得在創建目標庫時,把時區參數(default_timezone)調整得和源庫一模一樣。
📝總結
GCP 的 Database Migration Service(DMS)本質上是一個
免費的無伺服器(Serverless)遷移工具
(你只需要支付遷移過程中目標庫的硬件和網絡費用,DMS 本身不收軟件費)。
它把曾經高門檻、高風險的「手動人肉遷庫」,變成了標準化、可視化的點點鼠標。
最後一句話總結:
不要再用停機維護的舊思維去折騰生產環境了。 利用 DMS 做持續增量同步,把主動權抓在自己手裡,白天喝著咖啡就能把庫遷完,這才是現代雲原生運維該有的優雅姿勢!
