數據庫無縫遷移:使用GCP數據庫遷移服務實現MySQL平滑上雲

在互聯網公司的架構演進中,最讓人驚心動魄、如履薄冰的任務,絕對非「數據庫遷移」莫屬。

傳統的數據庫遷移就像是在高速公路上給狂飆的車換輪胎。 為了保證數據一致性,老舊的做法通常是選擇在凌晨三點掛起停機公告,切斷所有前端流量,然後用

mysqldump

導出一個幾十 GB 的大 SQL 文件,再慢吞吞地往雲端傳輸、導入。 結果往往是因為網絡抖動中斷、或者導入速度太慢,導致天亮了還沒導完,最後只能在全員高壓下被迫回滾,不僅讓研發團隊掉光了頭髮,還嚴重影響了公司的核心業務。

在 Google Cloud(GCP,谷歌雲)的現代化生態裡,有一個專為打破這個僵局而生的降維打擊神器,叫做

Database Migration Service(數據庫遷移服務,簡稱 DMS)

。

它的核心邏輯非常純粹:

全託管、零停機、無縫實時同步

。 通過結合 MySQL 原生的 Binlog 複製技術,DMS 能夠在線上業務照常開門接客的同時,在後台把老數據庫的數據像流水一樣源源不斷地搬上雲端。 等兩邊數據完全對齊後,你只需要挑一個風平浪靜的下午,花幾秒鐘把前端的連接字符串輕輕一改,就能完成大廠級別的「平滑上雲」。

今天我們不扯複雜的密碼學公式,拒絕任何廢話。 直接從硬核實戰切入,手把手帶你完成從本地自建 MySQL 到谷歌雲

Cloud SQL for MySQL

的無縫遷移演練。

第一階段:深度拆解,DMS 實時遷移的「兩階段物理世界模型」

在去控制台點鼠標之前,你必須在腦子裡建立起 DMS 底層的物理運行模型,否則你絕對會被複雜的網絡和權限配置給繞暈。

DMS 的全量 增量實時遷移,本質上是在谷歌內網底層搭建了一條高可用的數據傳輸管道,整個生命周期分為兩個核心階段:

第一階段:存量大盤初始化(Full Dump):當你啟動遷移任務時,DMS 會在不影響你源庫正常讀寫的前提下,閃電般地把源庫當前存量的所有表結構、數據打包克隆一份,快速投遞到雲端的 Cloud SQL 目標庫里。

第二階段:增量流水追趕(CDC/Binlog 複製):存量搬完的瞬間,DMS 會無縫切換到持續數據捕獲(CDC)模式。 它會化身為一個標準的 MySQL Slave(從庫),死死盯著源庫的 Binlog(二進製日誌)。 只要線上用戶下了一個新訂單、改了一個密碼,DMS 就會在毫秒級把這條

增量修改「抓」過來,在雲端目標庫里重放一遍。

核心架構結論:在這兩個階段里,你的老數據庫全程保持對外營業,不需要停機哪怕一秒鐘。 雲端新庫就像是老庫的影子,亦步亦趨,直到兩邊的數據時差(Replication Lag)歸零。

第二階段:實戰前夜--在自建源數據庫拉起「通行證」

為了讓 DMS 能合法地進來搬磚,我們必須先回老家(本地自建的 MySQL 源庫)做一些底層配置。

1. 開啟 Binlog 日誌(注入實時複製靈魂)

打開你源庫的

我的設定檔案

或

My.ini

配置文件,確保以下行沒有被注釋,並且參數正確:

Ini, TOML

[Mysqld]

Log-bin=mysql-bin

Binlog_format=ROW # 必須是 ROW 格式,DMS 靠這個精準識別每一行數據的變動

Server-id=100001 # 給源庫指定一個唯一的集群身份 ID

Expire_logs_days=7 # Binlog 至少保留 7 天,防止 DMS 還沒來得及讀就被系統自動刪了

改完後,記得重啟一下你的自建 MySQL 讓配置生效。

2. 創建 DMS 專屬「接頭人」賬號

連入源庫,敲入以下大廠規範的 SQL 命令,為 GCP DMS 創建一個擁有專屬複製權限的安全賬號:

SQL

-- 創建一個叫 gcp_dms 的賬號,允許它從任意地方(或指定 GCP 內網段)過來連

CREATE USER 'gcp_dms'@'%' IDENTIFIED BY 'YourHardPassword123! ；

-- 授予基礎的數據讀取與集群複製權限(大廠最小權限原則)

GRANT SELECT, RELOAD, SHOW DATABASES, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'gcp_dms'@'%';

-- 刷新權限,讓暗號瞬間生效

FLUSH PRIVILEGES;

第三階段:實戰演練--手把手配置 DMS 遷移流水線

環境準備就緒,我們登錄

GCP 管理主控台

，搜尋並進入

Database Migration(數據庫遷移)

頁面。

步驟 1:創建遷移作業(Migration Job)

點擊頂部的 「創建遷移作業」:

作業名稱:mysql-to-cloudsql-prod。

源數據庫引擎:選擇 MySQL。

目標數據庫引擎:選擇 Cloud SQL for MySQL。

遷移類型:毫不猶豫選擇 「持續(Continuous)」。 註:只有選 Continuous 才是帶增量同步的無縫平滑遷移;如果選 One-time(一次性),數據搬完就戛然而止,無法做到零停機切換。

步驟 2:定義源連接配置文件(Source Connection Profile)

在這裡,我們要把第二階段在老家配好的參數告訴谷歌:

連接型配置文件名稱:source-local-mysql。

主機名/IP 和端口:填入你本地 MySQL 的公網 IP 或專線內網 IP,端口默認 3306。

用戶名與密碼:精準填入剛才建好的 gcp_dms 及其密碼。

步驟 3:定義雲端目標庫(Destination)

你要把數據搬到哪裡去? DMS 在這裡提供了一個極其無敵的功能--

一鍵在後台幫你把全新的 Cloud SQL 目標庫直接新建出來

。

輸入你要新建的雲端數據庫實例 ID(如 cloudsql-mysql-prod)。

選擇 MySQL 的版本(建議與源庫保持一致,如 8.0)。

選擇地域(如 asia-east1 台灣)。

設置雲端 root 賬號的強密碼,並選擇機器規格(如 2核 4GB 內存,生產環境記得勾選「高可用性高防線」以啟用跨可用區雙活容災)。

步驟 4:連通性攻堅戰(Connectivity Method)-- 斬斷黑客窺探

這是最容易踩坑卡殼的地方。 谷歌雲的 DMS 怎麼穿過防火牆去連你本地的機器? DMS 提供了三種標準連通方式:

高級推薦方案:反向 SSH 隧道(Reverse SSH Tunnel):DMS 會在後台生成一個極輕量的中間 VM 虛擬機,並給你一串 SSH 命令。 你只需要在本地服務器上運行這串命令,就能在本地和 GCP 內網之間拉起一條全加密、穿透防火牆的秘密單向隧道。 你根本不需要在公司防火牆上給全球大開 3306 端口,安全係數直接掛滿。

備選方案:IP 允許列表:把 GCP DMS 提示你的那組官方公網 IP 地址,死死鎖進你本地機房最外層的硬件防火牆白名單里。

連通性測試通過後,點擊最底部的

「創建並啟動作業(Create &

Amp; Start Job)」

。

第四階段:見證奇蹟的時刻--線上實時追趕與終極斷流一切換

點擊啟動後,DMS 巨大的彈性分布式算力會被瞬間喚醒。 回到遷移作業列表,你會盯著狀態欄目睹它神奇的生命周期演變:

狀態從 Creating 變成 Starting,再進入 Full dump in progress(代表它正在拼命搬運你過去幾年沉澱的存量老數據)。

存量搬完後,狀態會變成綠色的 CDC in progress(持續複製中)。

此時,去控制台看一眼

「複製延遲(Replication Lag)」

指標。 剛開始由於存量搬運期間產生的新變動,延遲可能會有幾分鐘;但很快,隨著谷歌強大的內網帶寬火力全開,

Replication Lag 會徹底歸零(0 seconds)

。

這意味著,此時此刻,你本地老庫里的每一條數據,和谷歌雲端 Cloud SQL 新庫里的數據,已經達到了

絕對的、像素級的完全實時同步

。

大廠級標準的「黃金切流」操作五步法:

當延遲穩定在 0 秒後,我們就可以挑一個業務低谷期(比如下午 4 點用戶訪問最少的時候),進行最後的斷流一切換。 整個過程只需 10 秒鐘:

前端掛起臨時只讀:在你的 Web 應用後台,或者在 MySQL 源庫里執行 SET GLOBAL read_only = 1;,將老庫強行變成「只讀狀態」。 這個動作用來絕對確保在切換的這幾秒鐘內,不會有任何一筆新訂單能偷偷寫進老庫、從而造成兩邊數據脫節。

靜待最後查缺補漏:盯著 DMS 控制台,等待 5 秒鐘,讓最後一丁點正在傳輸的 Binlog 尾巴徹底在雲端重放完畢,確保兩邊數據一期不差。

點擊「升級(Promote)」大按鈕:在 GCP DMS 控制台,果斷點擊頂部的 「升級(Promote)」。 底層內幕:這個動作會瞬間切斷雲端新庫和老庫的奴隸復制關係。 Cloud SQL 目標庫會在一瞬間脫離從庫身份,滿血進化為一個完全獨立、可讀可寫的頂級主庫(Master)。

更換連接字符串:將你後端所有 Web 應用、微服務配置裡的數據庫連接 IP,從原本的老自建庫 IP,一鍵修改指向全新的 Cloud SQL 公網/內網 IP。

重啟應用,全盤復活:前端 App 重新連入雲端新庫,解除只讀。 新訂單開始在谷歌雲端以極高的性能瘋狂落盤。

完美收工!

整場戰役下來,用戶端只在第 1 步和第 4 步之間體驗到了極其輕微的、短暫的「無法下單/報錯」提示,網站整體從未掛過小黑屋公告,數據零丟失,上雲大獲全勝。

第五階段:跨國數據庫架構下的避坑血淚史

這套全託管遷移方案用起來優雅至極。 但要在真正的企業級高並發生產環境裡活下來,作為首席數據架構師,你必須防範以下兩個由於底層技術細節差異衍生出來的隱形大坑:

1. 致命的「時區與字符集(Collation)靈異錯亂」

很多團隊遷移完發現,線上運行了半年的老代碼,在連上雲端 Cloud SQL 之後,所有的中國時間、本地時間全部莫名其妙地少了 8 個小時。 或者某些包含生僻字、emoji 表情的用戶評論直接變成了亂碼或報錯。

原因拆解:本地自建的 MySQL 默認時區通常會跟著宿主機走(比如設為了系統時區 CST),而 GCP Cloud SQL 默認為了全球合規,其底層主時區強制鎖死為國際標準時間 UTC,字符集默認也可能與你的老庫有細微差別。

大廠標準避坑操作:在點擊 DMS 啟動遷移之前,去 Cloud SQL 的「配置更改」里,找到 數據庫標誌(Database Flags),顯式地添加 default_time_zone = ' 08:00'(或者契合你業務的主時區),並將字符集強行對齊為 utf8mb4。 在源頭卡死底層參數一致,是防止線上代碼報錯的第一鐵律。

2. DMS 遷移完後的「扣費沙漏閒置陷阱」

很多新手在完美升級(Promote)了數據庫、業務跑上雲端後,就高高興興地去下班吃火鍋了。 結果月底翻看賬單,發現產生了一筆莫名其妙、且價格不菲的 DMS 資源占用費。

硬核止損建議:當你點擊了「Promote」之後,DMS 這個遷移作業其實並沒有被徹底物理銷毀,它依然在雲端後台占領著臨時的計算資源和網絡網絡接口,扣費沙漏仍在瘋狂運轉。

正確姿勢:確認雲端新庫平穩運行 24 小時、確認不需要回滾後,必須立刻回到 DMS 控制台,選中那個已經完成的遷移作業,無腦點擊「刪除(Delete)」。 別擔心,刪除作業絕不會對你已經進化成功的 Cloud SQL 數據庫產生任何一絲一毫的影響,只有這樣,扣費才算徹底停止。

總結

利用 GCP Database Migration Service 進行數據庫無縫遷移,核心的工業級精髓就在於十六個字:

配置落鎖,

隧道打通,Binlog追趕,升級切流

。

你徹底告別了過去凌晨三點肉身盯防、提心吊膽的作坊式手工導出搬運。 把所有的網絡通信、大盤數據打包、實時狀態同步交由谷歌頂級的全託管安全大腦去克隆。 把核心的數據庫資產平穩、絲滑地焊死在雲端的高防地基之上,這才是現代雲原生時代最優雅、最地道的架構師通關姿勢。