實(shí)操指南：以無停機(jī)方式遷移SQL故障轉(zhuǎn)移集群

作者：核子可樂 2025-07-21 07:30:09

SQL宕機(jī)對許多企業(yè)來說已經(jīng)成為嚴(yán)重阻礙。報(bào)告管線會報(bào)錯、ERP系統(tǒng)會崩潰，即使是最簡單的用戶門戶也有可能癱瘓。無法承受這種連鎖反應(yīng)，我們只能選擇無縫遷移方案。

譯者 | 核子可樂

審校 | 重樓

運(yùn)行在老舊硬件或操作系統(tǒng)上的SQL Server故障轉(zhuǎn)移集群，往往很難以無宕機(jī)方式遷移至現(xiàn)代系統(tǒng)。我之前就面對過這類需求，將一個由HPE SAN支持的實(shí)時SQL集群遷移至Windows Server 2022新服務(wù)器，同時須保證依賴該集群的應(yīng)用程序零中斷正常運(yùn)行。以下是我們在完成這項(xiàng)工作中的一點(diǎn)心得體會。

業(yè)務(wù)運(yùn)行的巨大壓力，要求我們最大限度降低高峰運(yùn)營時段的停機(jī)風(fēng)險(xiǎn)。為此我們引入了額外的規(guī)劃、溝通和回滾驗(yàn)證環(huán)節(jié)。

為何必須遷移

原因有以下幾點(diǎn)：

原始節(jié)點(diǎn)已經(jīng)使用五年，且超出保修期。
我們的合規(guī)團(tuán)隊(duì)將操作系統(tǒng)版本（Windows Server 2019）標(biāo)記為即將停止支持。
我們希望借此調(diào)整配置決策，消除偶爾出現(xiàn)的故障轉(zhuǎn)移延遲。

這樣的基礎(chǔ)設(shè)施升級肯定不簡單，特別是在涉及關(guān)鍵SQL工作負(fù)載的情況下。

我們的設(shè)置（遷移前）

雙節(jié)點(diǎn)主-被動SQL Server 2019集群。
托管在Windows Server 2019系統(tǒng)上。
后端：具有多路徑I/O的HPE SAN。
通過DNS設(shè)置集群監(jiān)聽器。
.NET與報(bào)表工具會全天候訪問集群。

我們計(jì)劃引入兩個運(yùn)行有Windows Server 2022的新節(jié)點(diǎn)，緩慢遷移所有內(nèi)容，并在不中斷服務(wù)的情況下停用舊節(jié)點(diǎn)。

我們還與網(wǎng)絡(luò)和存儲團(tuán)隊(duì)密切合作，在啟動操作之前先行驗(yàn)證iSCSI配置與多路徑穩(wěn)定性。

我們的遷移計(jì)劃

相較于直接遷移，我們決定：

將新服務(wù)器添加至現(xiàn)有集群。
以“添加節(jié)點(diǎn)”模式在新服務(wù)器中安裝SQL Server。
將集群角色遷移至新節(jié)點(diǎn)。
在完全驗(yàn)證后移除舊節(jié)點(diǎn)。

這樣，我們就能在遷移底層基礎(chǔ)設(shè)施時，保證SQL實(shí)例、監(jiān)聽器名稱與磁盤均保持不變。

我們的分步操作流程

1. 準(zhǔn)備新服務(wù)器

我們將新服務(wù)器添加至域內(nèi)，對其進(jìn)行全面修復(fù)，并認(rèn)真檢查了多路徑驅(qū)動程序是否支持SAN訪問。期間我們還差點(diǎn)忽略了一個重要細(xì)節(jié)：某個節(jié)點(diǎn)上的iSCSI啟動器服務(wù)未設(shè)置為自動。這個小小的配置問題一旦爆發(fā)，很可能會耗費(fèi)幾小時的排查時間。

2. 加入集群

我們在故障轉(zhuǎn)移集群管理器添加了兩個新節(jié)點(diǎn)，PowerShell功能不受影響：

Add-ClusterNode -Name "UB-Prod-SQLA" -Cluster "SQLCluster"

Add-ClusterNode -Name "UB-Prod-SQLB" -Cluster "SQLCluster"

每次加入后，必須驗(yàn)證仲裁與見證設(shè)置。

3. 安裝SQL Server

在每個新節(jié)點(diǎn)上，我們使用SQL安裝UI“將節(jié)點(diǎn)添加至現(xiàn)有故障轉(zhuǎn)移集群”。我們對齊了現(xiàn)有實(shí)例名稱與安裝路徑，以避免后續(xù)出現(xiàn)問題。這里提醒大家，安裝程序在檢查集群角色時可能會短暫掛起，耐心等待即可。

4. 轉(zhuǎn)移SQL角色

我們使用PowerShell完成了簡潔切換：

Move-ClusterGroup-Name"SQL Server (MSSQLSERVER)"-Node"UB-PROD-SQLA"

我們密切關(guān)注CPU/內(nèi)存及應(yīng)用程序日志。切換過程很快完成——應(yīng)用層大約掛起了30秒，但沒有出現(xiàn)事務(wù)失敗。

5. 剔除舊節(jié)點(diǎn)

經(jīng)過幾天的性能觀察與故障轉(zhuǎn)移，我們開始剔除舊節(jié)點(diǎn)：

Remove-ClusterNode-Name"SQLSERVER01"-Force

在移除第二個節(jié)點(diǎn)之前，我們備份了集群配置并記錄了磁盤所有關(guān)系，以防發(fā)生意外。

而后使用PowerShell移除了第二個節(jié)點(diǎn)：

Remove-ClusterNode-Name"SQLSERVER02"-Force

最終我們成功遷移到兩個新的SQL Server節(jié)點(diǎn)，未引發(fā)任何停機(jī)時間，高可用性亦未受到影響。

6. 清理工作

我們清理了過時的DNS條目，重新注冊了監(jiān)控代理，并驗(yàn)證了所有作業(yè)仍在SQL代理中正常運(yùn)行。我們還激活了完整集群驗(yàn)證報(bào)告，確保所有操作均順利通過。

讓我們措手不及的意外：

分區(qū)不匹配：一個LUN映射不正確——通過手動比較WWN解決了此問題。
SQL代理：故障轉(zhuǎn)移后，由于腳本中包含硬編碼的節(jié)點(diǎn)名稱，因此一項(xiàng)作業(yè)靜默失敗。
防火墻規(guī)則滯后：盡管端口已經(jīng)打開，但GPO需要一段時間才能應(yīng)用；我們不得不手動啟動gpupdate /force。
監(jiān)控誤判：我們的監(jiān)控工具將正常的故障轉(zhuǎn)移誤判為需要手動重新配置的情況。

幾點(diǎn)小提示

在安裝SQL前驗(yàn)證MPIO與SAN的訪問權(quán)限。
使用PowerShell執(zhí)行可重復(fù)操作。
手動故障轉(zhuǎn)移前，務(wù)必進(jìn)行測試。
如果已部署有虛擬化環(huán)境，請創(chuàng)建集群配置快照。
在啟動前，記錄每個節(jié)點(diǎn)擁有哪些磁盤。
專門測試SQL代理作業(yè)，留意其中硬編碼形式的路徑或節(jié)點(diǎn)名稱。
使用 cluster log /g 捕捉歷史故障轉(zhuǎn)移事件，以便日后進(jìn)行故障排查。
將各個階段告知應(yīng)用團(tuán)隊(duì)——即使是短暫的故障轉(zhuǎn)移也可能觸發(fā)警報(bào)。

寫在最后

整個遷移過程并不簡單，令人緊張、細(xì)節(jié)繁瑣，但又無比重要。干凈利落地完成遷移，完全不引發(fā)用戶注意，正是區(qū)分優(yōu)秀基礎(chǔ)設(shè)施團(tuán)隊(duì)和卓越團(tuán)隊(duì)的關(guān)鍵差異。

我們還發(fā)現(xiàn)，事后編寫一份內(nèi)部快速行動手冊會很有幫助。現(xiàn)在，組織內(nèi)的其他團(tuán)隊(duì)可以輕松重復(fù)整個過程，規(guī)避我們之前犯過的錯誤。

在生產(chǎn)環(huán)境中，整個遷移過程只有一次機(jī)會。所以務(wù)必整理好回滾計(jì)劃，知會值班人員，也絕不能樂觀認(rèn)定預(yù)發(fā)布階段中奏效的方法可以直接在生產(chǎn)環(huán)境中成功。希望這篇文章能給大家一點(diǎn)啟發(fā)，幫助各位順利完成自己的遷移任務(wù)。

原文標(biāo)題：Migrating SQL Failover Clusters Without Downtime: A Practical Guide，作者：Kishore Thota

責(zé)任編輯：姜華來源： 51CTO