SQL Server HA 與 DR – 選擇哪一個 – 清單和指南

業務連續性的支柱

在現代企業中，數據是運營的命脈，其持續可用性是不容忽視的。對於依賴 Microsoft SQL Server 的組織來說，高可用性 (HA) 和災難恢復 (DR) 構成了彈性數據策略的兩大支柱。雖然經常一起討論，但它們解決的是根本不同的故障，並且具有不同的目標、範圍和機制。全面的計劃並不是要選擇其中一個，而是要選擇其中一個。它是關於對兩者進行智能分層，以創建一個縱深防禦架構，該架構可以承受從輕微服務器故障到災難性數據中心丟失等各種故障。

高可用性 (HA)：不間斷服務的要求

高可用性是一組技術和架構原則，專注於一個主要目標：通過消除特定物理位置內的單點故障來確保服務的持續運行。 HA的核心目標是服務可用性。它旨在使數據庫和應用程序保持在線狀態，並通過局部故障供用戶訪問，將任何中斷降至最低甚至不存在。 HA 解決方案的根本目的是在面對常見的組件級故障時“保留服務”。

真正的 HA 解決方案的定義特徵是它依賴於自動、快速的故障轉移。當主要組件檢測到故障時，系統會自動將操作重定向到冗餘備用組件，無需人工干預。該過程的設計速度極快，通常以秒為單位，以滿足嚴格的服務級別協議 (SLA) 的正常運行時間。

災難恢復 (DR)：災難生存策略

災難恢復包括在發生導致主要運營站點無法使用的災難性事件後重建關鍵技術基礎設施和系統的整體戰略、政策和程序。災難恢復的主要目標是服務連續性，即從地理獨立的輔助位置恢復業務功能的能力。與旨在防止停機的 HA 不同，DR 承認會發生停機，並專注於最大限度地減少其持續時間和影響。災難恢復計劃的核心目的是“保留數據”並在重大中斷後恢復提供服務的能力。

調用災難恢復計劃的機制通常是手動或精心安排的故障轉移。故障轉移到不同區域的決定是一項具有廣泛影響的重要業務決策，因此很少能完全自動化。此過程本質上比 HA 故障轉移慢，恢復時間以分鐘或小時為單位。

高可用性 (HA)

目標：不間斷的服務

HA 專注於消除單個位置內的單點故障。它提供自動、快速的故障轉移，以便在服務器崩潰或操作系統故障等局部故障期間保持服務在線。

• 範圍：本地（同一數據中心）
• 目標：保留服務
• 故障轉移：自動且快速（秒）
• 比喻：一場比賽中的替補四分衛。

災難恢復 (DR)

目標：在災難中倖存

災難恢復是在災難性事件導致主站點無法使用後重建系統的策略。它專注於從地理獨立的輔助位置恢復服務。

• 範圍：地理（不同地區）
• 目標：保留數據
• 故障轉移：手動且較慢（分鐘/小時）
• 比喻：疏散到指定避難所。

轉化業務需求：RTO 和 RPO

在選擇技術之前，您必須定義企業對停機和數據丟失的容忍度。 RTO 和 RPO 這兩個指標將控制 HADR 策略中的每個決策。

恢復點目標 (RPO)

“我們可以承受丟失多少數據？”

RPO 測量最大可接受的數據丟失量，從故障時刻向後測量。接近零的 RPO 需要同步數據複製，而更高的 RPO 可以通過日誌傳送或備份等異步方法來滿足。

恢復時間目標 (RTO)

“我們必須多快恢復上線？”

RTO 定義了可接受的最長停機時間。接近於零的 RTO 需要完全自動化的故障轉移解決方案，而較高的 RTO 則允許手動恢復過程。

按技術劃分的 RTO/RPO

SQL Server HADR 技術組合

SQL Server 提供了豐富的技術組合。了解每個的架構和用例至關重要。

始終在線可用性組 (AG)

一流的集成 HADR 解決方案，提供數據庫級別的保護。其無共享架構為單個框架內的 HA（通過同步提交）和 DR（通過異步提交）提供了令人難以置信的靈活性。

始終在線故障轉移集群實例 (FCI)

在服務器實例級別提供保護的傳統方法。 FCI 依賴於共享存儲，是純本地 HA 解決方案，可保護整個實例，包括系統數據庫和 SQL 代理作業。

日誌傳送

簡單、可靠且經濟高效的災難恢復解決方案。它的工作原理是自動備份主服務器上的事務日誌並在輔助服務器上恢復它們​​。這是一個具有可配置 RPO 的手動故障轉移過程。

備份與恢復

任何戰略的基本組成部分。雖然複製可以防止基礎設施故障，但只有從備份進行時間點恢復才能從邏輯數據損壞或人為錯誤中恢復。

架構師的決策矩陣

使用此清單可以快速評估哪些解決方案符合您的技術、業務和財務限制。

過濾依據：

全部
哈
DR

所有版本
企業
標準

數據保護的物理原理：網絡延遲

同步和異步複製之間的選擇是零數據丟失和應用程序性能之間的直接權衡，這種權衡完全由網絡延遲控制。

同步與異步提交模式

同步提交（HA）

理想延遲：< 5ms

1
客戶端發送COMMIT

2
Primary 將日誌發送到 secondary

3
二次強化日誌和 ACK

4
Primary 向客戶端確認 COMMIT

結果：零數據丟失，但事務延遲增加。

異步提交（DR）

容忍高延遲

1
客戶端發送COMMIT

2
Primary 向客戶端確認 COMMIT

3
主節點將日誌發送到輔助節點（無需等待）

4
稍後進行二次硬化日誌

結果：性能影響最小，但可能會丟失數據。

可用性的經濟性：SQL Server 版本支持

HADR 架構的選擇很大程度上受成本影響，而成本主要取決於 SQL Server 版本。

按版本劃分的關鍵 HADR 功能

應對異構性：支持混合配置

在理想情況下，HADR 拓撲中的所有服務器都是相同的。然而，分階段的硬件更新、軟件升級和預算週期等實際情況往往會導致異構環境可行性的問題。了解混合 SQL Server 版本、版本和硬件的規則對於維護穩定且受支持的解決方案至關重要。

混合 SQL Server 版本和版本

微軟的支持政策很明確：對於永久的生產環境，單個AG或FCI中的所有實例必須運行相同的主要版本和版本的SQL Server。如果數據庫使用僅限企業版的功能，從企業版到標準版的故障轉移可能會導致失敗。

關鍵的例外是在滾動升級期間。此過程允許臨時混合版本 AG 以最短的停機時間升級 SQL Server。這是一個受支持的維護程序，而不是永久性設計。對於數據庫格式來說，從舊版本到新版本的故障轉移是一種單向旅行；在舊實例也升級之前，您無法進行故障回复。

混合硬件配置

雖然技術上可行，但強烈建議不要對 AG 或 FCI 中的節點使用不同的硬件規格（CPU、內存、存儲）。整個系統的性能通常由其最薄弱的環節決定。

• 同步AG：較慢的輔助副本的I/O將成為瓶頸，並直接減慢主服務器上的每個寫入操作。
• 故障轉移時：如果新的主服務器功能較弱，應用程序性能將急劇下降，可能違反 SLA。

最佳實踐是確保所有潛在的主節點具有相同或非常相似的硬件配置。

混合配置支持矩陣

關鍵考慮因素：混合版本/版本環境是維護的臨時狀態，而不是永久設計。性能的可靠性取決於集群中最弱的節點。

交互式決策樹

選擇正確的 HADR 解決方案可能很複雜。回答以下問題，以獲得根據您對恢復、範圍和預算的具體需求的個性化建議。

有關的：報表服務器到服務器的遷移路徑指南 – 清單和腳本

重新開始

常見的架構模式

根據分析，出現了幾種常見且有效的架構模式來滿足不同的組織需求。

模式 1：最大可用性和災難恢復

“成本不是問題”模式

利用多站點、多區域分佈式可用性組。通過將用於 HA 的本地同步 AG 與用於 DR 的異地複制異步 AG 相結合，提供盡可能高水平的恢復能力。

需要：SQL Server 企業版。

模式 2：成本優化的 HA/DR

“標準版主力”模式

將用於本地 HA 的兩節點故障轉移集群實例 (FCI) 與用於遠程 DR 的日誌傳送相結合。這提供了僅使用標準版功能的完整且強大的 HA+DR 解決方案。

需要：SQL Server 標準版。

模式 3：雲混合彈性

現代災難恢復方法

使用公共雲（Azure、AWS）作為經濟高效的災難恢復站點。本地主服務器通過安全網絡連接複製到可用性組中基於雲的輔助副本。

需要：SQL Server Enterprise 或 Standard（帶有 Basic AG）。

最終建議

HADR 實施只是一個開始。為了確保它在需要時發揮作用，持續的文檔、測試和監控循環至關重要。

• 記錄一切：創建全面的災難恢復計劃，其中包括通信協議以及故障轉移和故障恢復的分步過程。
• 測試、測試和再測試：定期安排和執行 DR 測試，以驗證您的 RTO/RPO 目標在實踐中是否能夠實現。未經檢驗的計劃只是一個假設。
• 大力監控：主動監控集群健康狀況、AG 同步狀態和數據丟失滯後。使用 DMV 並配置警報以在問題變成災難之前發現問題。

-- Check AG sync state and potential data loss
SELECT 
    replica_server_name, 
    database_name, 
    synchronization_state_desc, 
    synchronization_health_desc,
    last_hardening_lsn,
    log_send_queue_size,
    log_send_rate,
    redo_queue_size,
    redo_rate
FROM sys.dm_hadr_database_replica_states