Azure微軟雲購買:使用Azure Database Migration Service實現本地SQL Server零遷移遷移

在企業 IT 架構向雲原生演進的過程中,最讓 CIO 睡不著覺、讓 DBA 掉光頭髮的業務場景,莫過於

核心數據庫遷移上雲

。

很多公司在面對幾十個 GB 甚至數個 TB 的本地 SQL server 數據庫時,往往採用最原始的「停機斷網、備份導出、跨網傳輸、雲端還原」四部曲。 這種做法在小作坊式的邊緣業務里勉強能跑通,但在面對金融、電商、或者 24 小時高頻運轉的生產系統時,無異於一場自殺式的豪賭:光是把幾百個 GB 的備份文件通過公網或專線跨海傳輸,就需要好幾個小時。 在這期間,整個公司的業務必須完全停擺、掛起「系統維護」的白屏。 一旦傳輸中斷或者雲端還原報錯,漫長的回滾過程不僅會拖垮當季度的 KPI,更會讓企業面臨難以承受的財務損失。

為了徹底降維打擊這種「停機時間長、遷移風險高」的行業痛點,微軟雲(Azure)掏出了一款專為數據庫現代化量身定製的無縫搬家神器--

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

。

它的核心邏輯強硬且優雅:

利用在線數據流持續複製(Online Migration),實現近乎「零停機時間(Near-Zero Downtime)」的平滑遷移。

它的工作原理非常像在本地和雲端數據庫之間插了一根「實時輸血管」:在遷移開始時,它會先做一次全量的數據底盤同步;隨後,本地數據庫即便依然在瘋狂接收新訂單、改寫新數據,DMS 也會通過讀取事務日誌,把這些增量數據以毫秒級的延遲實時「倒灌」到雲端的 Azure SQL Database 中。 等到兩邊的數據完全對齊、差異壓縮到幾秒鐘時,你只需要挑一個夜深人靜的時刻,點擊「斷開切流」,業務便能在幾秒鐘內平滑切換到雲端。

今天我們拒絕任何官方概念的堆砌,不扯無聊的教科書參數。 直接從最硬核的現代化生產實戰切入,手把手帶你用大廠規範,10 分鐘在雲端布設好這根實時輸血管,將本地的 SQL Server 完美、零風險地送上雲端。

第一階段:深度拆解,在線零停機遷移的「三維管道模型」

在動手去 Azure 控制台點鼠標之前,你必須在腦子裡建立起 DMS 在線遷移底層的數據流動模型。 很多人在配置時頻繁報錯,就是因為沒搞懂這三者之間是如何對齊暗號的:

源頭陣地:本地物理機/虛擬機中的 SQL Server:這是你的生產命脈。 為了實現「在線不掉線」的

增量同步,本地數據庫必須開啟完全恢復模式(Full Recovery Model),並且必須進行過至少一次完整的備份。 這是為了讓 DMS 能夠順藤摸瓜,通過讀取你的事務日誌(Transaction Log)來捕捉每一名用戶剛剛發生的下單或改密動作。

黃金搬運工:Azure DMS(全託管遷移引擎):這是坐鎮在雲端的一個高防、高並發的 PaaS 計算集群。 它就像一輛不知疲倦的數字大卡車。 為了能同時拉到本地數據庫和雲端數據庫的手,DMS 實例必須被部署在能夠通過物理專線(ExpressRoute)或高防 VPN 穿透進入你本地內網的虛擬網絡(VNet)中。

雲端接盤俠:Azure SQL Database(或 SQL 託管實例):這是遷移的終點站。 在遷移正式開啟前,它就像一個空房間。 DMS 會先在這裡像素級克隆出和本地一模一樣的表結構、索引和約束,然後開始源源不斷地接納倒灌進來的數據流。

第二階段:實戰演練--10 分鐘平地起高樓,架設 DMS 實時輸血管

請確保你已經提前在 Azure 上建好了一個乾淨的終點站:

Azure SQL Database

(或者 Azure SQL Managed Instance),並且本地機房與 Azure 虛擬網絡(VNet)之間的 VPN 專線已經完全打通。

步驟 1:開闢 DMS 全託管遷移工作區

登入 Azure 服務入口網站（Portal）。

在上方蒐索欄輸入 「Azure Database Migration Services」,點擊進入核心控制台。

點擊頂部的 「 Create」:基本信息:選好你的資源組,給遷移服務起名叫 dms-core-prod,地域選擇離你本地機房最近的(如 East Asia 香港)。 服務模式(Service Mode):極其關鍵,必須選擇「Azure Resource Manager」。 定價層(Pricing tier):如果想要玩轉「近乎零停機」的在線增量複製,必須精準選中「Premium」(高級版,支持 4 核算力)。 標準版只支持離線單次導出,只有高級版才能解鎖在線輸血管黑科技,而且微軟目前針對該服務提供了非常優厚的基礎測試免費額度。 虛擬網絡(Virtual Network):精準選中那條與你本地機房通過 VPN/專線互聯的 VNet。

點擊創建。 微軟的無伺服器編排引擎

會在後台為你打磨這個遷移網關,大約 3 分鐘左右服務就會滿血在線。

第三階段:實戰演練二--降維打擊,開啟在線實時數據倒灌

當 DMS 實例的狀態亮起綠色的

成功了

時,最硬核的搬家戰役正式打響。 點擊進入該 DMS 實例。

1. 新建遷移大盤項目(New Migration Project)

點擊頂部的 「 New Migration Project」。

Project name:起名叫 proj-sql-to-azure。

Source server type:選擇 SQL Server。

Target server type:選擇 Azure SQL Database(根據你的雲端接收端選擇)。

Choose type of activity(選擇活動類型):注入靈魂的一步,必須、堅決選中「Online data migration」(在線數據遷移)。

2. 對齊兩界接頭暗號

點擊下一步,來到源站和目標站的憑據填寫頁面:

Source details(源詳細信息):輸入你本地 SQL Server 的內網 IP 地址、端口號,以及具有 sysadmin 權限的 DBA 賬號密碼。

Target details(目標詳細信息):輸入你 Azure SQL Database 的服務器域名(例如 sql-prod-srv.database.windows.net)以及雲端的管理員賬號密碼。

選擇數據庫:系統會自動隔空抓取本地 SQL Server 里的所有數據庫列表。 勾選你需要搬家的核心業務庫(如 db_ecommerce)。

3. 布設中間中轉站(網絡共享路徑)

在線遷移需要一個本地和雲端 DMS 都能讀寫的中轉站,用來臨時存放事務日誌備份。

在網絡位置表單里,輸入一個你本地機房裡的 SMB 網絡共享路徑(如 \\local-nas\sql_backup)。

輸入能夠讀寫該路徑的域賬號密碼。 DMS 會通知本地 SQL Server 把增量日誌源源不斷地吐到這個共享目錄里,然後 DMS 再從這裡把日誌抓取、解析、並高頻重放到雲端。

連續點擊下一步,最後按下

「Start Migration」(啟動遷移)

。

第四階段:見證奇蹟的現場--秒級斷聯,業務無縫搶灘登陸

點擊啟動後,點擊進入這個激活的遷移任務

(Migration Activity)詳情頁。

你會看到一個非常直觀的流式監控大盤:

全量加載階段(Full Load):DMS 正在後台瘋狂把本地現存的存量數據打包、閃電般克隆到雲端。

增量同步階段(Incremental Sync):全量跑完後,狀態會變成 Syncing。 此時,你讓開發在本地數據庫里故意插入一條測試訂單,你會發現大盤里的 「增量更新計數器」 瞬間跳動,在不到 1 秒鐘內,這條新訂單就已經在幾千公里外的 Azure 雲端數據庫里安穩落盤。 兩邊的數據差(Downtime Time Capacity)被死死壓縮在 2 秒以內。

終極切流切線時刻(Cutover)

當狀態死死保持在

Ready to Cutover

(準備好切換)時,說明上雲的衝鋒號已經吹響。

下達行政命令:通知前端開發,將本地 APP 或網站的連接池臨時變更為「只讀」,或者短暫掛起前端幾秒鐘,確保本地數據庫不再產生任何新的數據寫入。

等待大盤里的「未遷移事務」徹底清零、延遲變成 0 秒的瞬間。

一鍵飛升:在 DMS 詳情頁頂部,果斷按下 「Complete Cutover」(完成切換) 按鈕。 DMS 會把最後兩秒鐘的殘留日誌強行重放完畢,然後徹底安全地斬斷兩界通道。

運維全速將前端 APP 的數據庫連接字符串(Connection String),一鍵修改指向雲端的 sql-prod-srv.database.windows.net,重啟前端服務。

全過程從停機、切流、到雲端滿血復活,

整條業務線的實質性停機時間被強行壓縮在了短短的 15 秒到 1 分鐘之內

。 海外買家甚至只是感覺手機上的網頁輕微刷新了一下,整座企業的數字帝國大後方就已經神不知鬼不覺地在微軟雲的頂級高防機房裡順利會師、搶灘登陸成功。

第五階段:工業級零停機遷移下的避坑血淚史

這套遷移方案在實戰中的優雅程度堪稱藝術。 但要在真正的企業級大流量、嚴苛的生產審計戰場裡穩定活下來,作為首席數據庫架構師,你必須在合攏電腦前,順手焊死以下兩個由於在線同步引發的現實大坑:

1. 致命的「本地磁盤被爆滿」隱患(Log Chain Broken)

在線遷移期間,DMS 需要高頻地去本地讀取和清理事務日誌備份。

災難發生:如果你的本地生產庫並發極高(比如每秒幾萬條寫入),而你本地機房分給共享備份目

錄(SMB Path)的磁盤空間非常局促。 一旦由於跨國網絡輕微抖動,導致雲端的 DMS 抓取日誌的速度變慢了,本地的 SQL Server 依然在瘋狂地把日誌吐進這個目錄,在幾個小時內就會把本地存儲空間徹底塞爆(disk Full),直接反向導致你本地的生產數據庫當場因缺空間而腦死亡掛掉。

大廠標準免死金牌規範:在開啟 DMS 前,必須給本地共享備份盤劃出至少 2 倍於日常日誌產生量的富餘空間,並且利用 Powershell 寫一個定時腳本:只要 DMS 已經成功確認重放(Acknowledged)了某批日誌,就自動在本地將其物理粉碎擦除。 用飽滿的物理預算去對衝網絡不確定性。

2. 嚴禁讓外鍵約束和觸發器在全量加載期「幫倒忙」

如果你的本地數據庫里設計了極其複雜的

外鍵約束(Foreign Keys)或者觸發器(Triggers)

(比如插入 A 表時,觸發器會自動去修改 B 錶)。

內幕曝光: 當 DMS 在執行第一步全量加載 (Full Load) 時, 它是多執行緒並行向雲端砸數據的。如果雲端的表結構默認開啟了高頻觸發器,DMS 剛塞進去一條數據,觸發器就會在雲端自作聰明地去改別的表,這不僅會導致數據產生嚴重的兩重衝突、賬目對不上,還會把雲端數據庫的 CPU 在一瞬間活生生頂爆,讓全量同步的速度慢得像烏龜爬。

硬核加固規範:先脫衣,後穿衣。 在編寫雲端 DDL 腳本時,先在雲端創建不帶外鍵約束、不帶觸發器的「裸錶」。 讓 DMS 全速、無阻礙地把所有海量數據以最高並發全部倒灌進去。 在點擊 Cutover(切換)的前夕,再通過一段標準的 SQL 腳本,一鍵把外鍵約束、觸發器和高頻索引在雲端「滿血恢復復活」。 順應數據庫的底層吞吐胃口去設計流水線,它才會給你回報真正的零失誤響應。

總結

利用 Azure Database Migration Service 實現本地 SQL Server 的在線零停機遷移,核心的工業級精髓其實簡化為十六個字:

全量打底,增量倒灌,日誌牽線,秒級切流。

你徹底告別了過去每次給數據庫搬家都要天天看網絡帶寬臉色、提心吊膽怕文件損壞、深夜拉著全公司熬夜停機打持久戰的原始作坊苦海。 把所有繁雜的分布式校驗和高頻重放,完全託管給雲大廠的 PaaS 級數據大腦。 坐在電腦前,看著兩端數據在眨眼間像素級對齊,優雅地敲一下回車,迎接雲原生時代的滿

血進化。