立即分享:

1. 簡介 SQL Server 高可用性

高可用性 SQL Server 指的是系統在面臨硬體原因、軟體問題或計畫內維護時,仍能以最小的停機時間保持運作的能力。高可用性的重要性不容小覷。一旦資料庫不可用,組織將面臨直接後果,包括…ost 收入下降、生產力降低、客戶不滿意。

雖然高可用性 (HA) 和災難復原 (DR) 經常被混用,但它們針對的是不同的故障情境。 HA 著重於最大限度地減少局部故障(例如伺服器或執行個體崩潰)造成的停機時間,而 DR 則旨在從影響整個資料中心或區域的大規模災難中恢復。

兩個關鍵指標指導高可用性規劃:

  • 復原時間目標 (RTO) 定義了故障發生後可接受的最大停機時間。
  • 恢復點目標 (RPO) 規定了可容忍的最大資料遺失量。

可用性通常以「9」來衡量:99.9%(三個9)允許每年停機8.76小時,99.99%(四個9)允許52.6分鐘,而99.999%(五個9)將停機時間限制在每年僅5.26分鐘。

2. SQL Server 高可用性解決方案概述

2.1 HA解決方案的類別

SQL Server 高可用性解決方案可以從以下幾個方面進行分類:

  • 執行個體層級保護與資料庫層級保護:執行個體層級保護(例如故障轉移叢集實例)可保護整個實例,包括所有資料庫和伺服器物件;而資料庫層級保護(例如 Always On 可用性群組)可保護特定資料庫。
  • 同步資料移動與非同步資料移動:同步資料移動可確保零資料遺失,但可能會引入延遲;而異步移動可最佳化效能,但可能會造成資料遺失。
  • 自動故障轉移與手動故障轉移:自動故障轉移無需人工幹預即可最大限度地減少停機時間,而手動故障轉移提供更大的控制權,但需要管理員操作。

2.2 常見的HA解決方案

SQL Server 提供八種主要高可用性解決方案,每種方案都針對特定場景:

  • 始終在線可用性組
  • 包含可用性組
  • 分散式可用性組
  • 故障轉移叢集實例
  • SQL Server 複製
  • 日誌傳送
  • 數據庫鏡像
  • 託管執行個體連結

3. Always On 可用性組

Always On 可用性組代表 SQL Server的頂級資料庫級高可用性和災難復原解決方案,於 SQL Server 2012 年。它使資料庫群組能夠作為一個整體一起發生故障轉移,同時提供可讀的輔助副本以進行查詢卸載。

Always On 可用性組概述

 

產品特色

  • 最多支援 9 個副本(1 個主副本 + 8 個從副本)
  • 同步提交模式下最多支援 5 個副本(1 個主副本 + 4 個從副本)
  • 同步模式下自動故障轉移,資料零遺失
  • 用於查詢卸載的可讀輔助副本
  • 將備份卸載到輔助副本
  • 用於自動連接路由的可用性群組監聽器
  • 用於負載平衡讀取查詢的唯讀路由
  • 多個資料庫作為一個整體同時發生故障轉移。

實施步驟

  • 設定 Windows Server 故障轉移叢集 (WSFC) 或 Linux Pacemaker 叢集
  • 在所有裝置上啟用 Always On 可用性群組功能 SQL Server 實例
  • 確保資料庫使用完整復原模式並擁有完整備份。
  • 在每個副本上建立資料庫鏡像端點
  • 建立可用性群組並新增資料庫。
  • 配置主副本和輔助副本所需的模式
  • 建立並配置可用性群組偵聽器
  • 如果使用可讀輔助設備,請設定唯讀路由。
  • 測試故障轉移程序並驗證應用程式連接性

最適合

  • 需要最大限度正常運作時間的關鍵任務資料庫
  • 需要本地高可用性和地理災難復原的組織
  • 需要讀取縮放功能的環境
  • 受益於卸載報表查詢的應用程式
  • 需要零資料遺失保護的資料庫
  • 需要協調故障轉移的多資料庫應用程式

優點

  • 同步提交模式下零資料遺失
  • 自動故障轉移可最大限度地減少停機時間(通常為幾秒鐘)。
  • 可讀性強的輔助記憶體可減輕主記憶體的負載
  • 無需共享存儲
  • 同時支援 Windows 和 Linux 平台
  • 災後復原的地理分佈
  • 備份作業可以卸載到輔助節點。
  • 故障轉移後,應用程式連接字串保持不變。

缺點

  • 要使用全部功能,需要企業版。
  • 標準版僅限 Basic AG(1 個資料庫,1 個輔助資料庫,無可讀輔助資料庫)
  • 複雜配置和管理
  • 需要叢集基礎設施(WSFC 或 Pacemaker)
  • 實例級物件(登入名稱、作業)需要手動同步
  • 同步模式可能會引入交易延遲。
  • 許可cost適用於多個伺服器

參考

4. 包含可用性群組

包含可用性組,於 SQL Server 2022 年,透過自動跨副本同步實例層級對象,擴展了傳統的 Always On 可用性群組,因此無需手動複製登入名稱、作業和其他伺服器層級物件。

包含可用性群組概述

產品特色

  • 自動同步實例級物件(登入名稱、使用者、角色)
  • SQL Server 代理作業已複製到所有副本
  • 資料庫權限自動同步
  • 包含所有始終在線的農業生產功能
  • 簡化故障轉移,實現完整的環境複製
  • 同時支援 Windows 和 Linux 平台

實施步驟

  • 請確保 SQL Server 2022 年或之後所有實例
  • 配置 WSFC 或 Pacemaker 叢集基礎架構
  • 在所有實例上啟用「始終開啟」功能
  • 建立包含可用性群組(帶 CONTAINED 選項)
  • 將資料庫新增至包含的 AG 中。
  • 在 AG 環境中建立登入名稱和作業
  • 配置監聽器並測試故障轉移

最適合

  • 希望簡化農業管理的組織
  • 頻繁進行故障轉移測試或操作的環境
  • 需要大量實例級物件的應用程式
  • New SQL Server 2022 年及以後的部署
  • 尋求降低 p 的團隊ost-故障轉移配置

優點

  • 無需手動同步登入資訊和作業
  • 更快、更可靠的故障轉移
  • 減少管理開銷
  • 應用程式在故障轉移後立即恢復運作。
  • 簡化的災難復原程序
  • 包括所有傳統農業福利

缺點

  • 要求 SQL Server 2022或更高版本
  • 要使用全部功能,需要企業版。
  • 無法將現有的傳統AG轉換為封閉式AG
  • 所有副本必須支援包含的 AG 功能
  • 與傳統AG相比,複雜性更高

參考

5. 分散式可用性組

分散式可用性群組(Distributed Availability Groups)於 SQL Server 2016 年,啟用「可用性群組的可用性群組」架構,將兩個獨立的可用性群組連接起來,跨越不同的集群,以實現進階災難復原和遷移場景。

分散式可用性群組概述

產品特色

  • 連接兩個獨立的可用性組
  • 每個AG都維護自己獨立的集群。
  • 跨平台支援(Windows 到 Linux)
  • 跨集群複製,無需共享集群成員資格
  • 一個AG作為主要AG,另一個作為次要AG。
  • 支援同步和非同步模式
  • 跨區域或跨大陸的地理分佈

實施步驟

  • 建立並配置第一個可用性群組(主DAG)
  • 建立並配置第二個可用性群組(輔助DAG)
  • 建立連接兩個 AG 的分散式 AG
  • 配置 AG 之間的資料同步
  • 在每個 AG 上設定監聽器以實現應用程式連接
  • 配置故障轉移策略和測試流程
  • 驗證跨集群通訊和複製

最適合

  • 跨獨立資料中心的多區域災難復原
  • 從 Windows 到 Linux 或反之亦然的跨平台遷移
  • 混合雲場景,將本地環境連接到 Azure
  • 主要版本升級需要延長遷移視窗期
  • 擁有多個獨立故障轉移集群的組織
  • 需要跨洲複製的全球企業

優點

  • 解耦站點間的群集依賴關係
  • 實現真正的地理分佈
  • 支援跨平台場景
  • 每個AG都可以獨立發生故障轉移。
  • 非常適合複雜的遷移項目
  • 無需共享叢集基礎設施
  • 可以跨越不同的Windows網域或Linux發行版

缺點

  • 需要企業版
  • 配置和管理的高度複雜性
  • 需要對集群和農業技術有深入的了解。
  • 比標準AG更難排除故障
  • 跨區域場景的額外延遲
  • 需要精心規劃故障轉移程序。

參考

6.故障轉移叢集實例(FCI)

故障轉移叢集執行個體利用共用儲存和 Windows Server 故障轉移叢集提供執行個體級高可用性,從而實現整個系統的自動故障轉移。 SQL Server 實例包括所有資料庫和伺服器級物件。

故障轉移叢集實例概述

產品特色

  • 實例級保護(所有資料庫同時故障轉移)
  • 採用共享儲存的主動-被動配置
  • 用於透明故障轉移的虛擬網路名稱 (VNN)
  • 當活動節點發生故障時,自動進行故障轉移
  • 零資料遺失(資料單份副本)
  • 伺服器級物件包括(登入名稱、作業、連結伺服器)
  • 支持全部 SQL Server 恢復模型

實施步驟

  • 配置 Windows Server 故障轉移群集 (WSFC)
  • 設定共享儲存(SAN、SMB、儲存空間直連)
  • 配置集群仲裁設置
  • 安裝 SQL Server 作為第一個節點上的故障轉移叢集實例
  • 向 FCI 新增其他節點
  • 設定虛擬網路名稱和 IP 位址
  • 測試叢集節點間的故障轉移
  • 配置客戶端應用程式以使用 VNN

最適合

  • 擁有現有共享儲存基礎架構的組織
  • 需要實例級保護的環境
  • 單一資料中心內的本地高可用性
  • 需要所有資料庫同時進行故障轉移的應用程式
  • 需要保護伺服器級物件的場景
  • 僅限 Windows 環境(FCI 不支援 Linux)

優點

  • 完整的實例級保護
  • 保證零資料遺失
  • 自動故障轉移能力
  • 無需同步登入資訊或作業
  • 資料單副本減少儲存空間osts
  • 支援所有恢復模式
  • 故障轉移後應用程式連接字串保持不變

缺點

  • 需要昂貴的共享儲存基礎設施
  • 共享儲存是單點故障
  • 無讀取擴展能力(只有一個活動節點)
  • 由於倉儲限制,地理分佈範圍有限。
  • 標準版僅限 2 個節點
  • 僅限 Windows 系統(不支援 Linux)
  • 與 AG 相比,故障轉移時間更長(通常為幾分鐘)。
  • 複雜的儲存配置和管理

參考

7. SQL Server 複製

SQL Server 複製是一種資料分發技術,它將資料複製並分發到多個伺服器,支援從簡單的單向分發到複雜的多主配置的各種拓撲結構,但主要用於報告,而不是純粹的高可用性解決方案。

ACEWAY 的 SQL Server 複製

產品特色

  • 四種複製類型:快照複製、交易複製、合併複製、點對點複製
  • 細粒度資料選擇(特定表、列、行)
  • 支持來自同一出版商的多個訂閱者
  • 提供雙向和多主拓撲結構
  • 靈活的日程安排和同步選項
  • 合併複製的衝突解決
  • 使用 WHERE 謂詞的過濾功能

實施步驟

  • 設定分發伺服器(可以與發布伺服器分開,也可以與發布伺服器相同)
  • 在 Publisher 資料庫中建立出版物
  • 根據需求選擇複製類型
  • 選擇要複製的文章(表格、檢視、預存程序)。
  • 如有需要,請配置篩選和資料轉換功能。
  • 設定訂閱者資料庫
  • 建立訂閱(推送或拉取)
  • 使用快照初始化訂閱
  • 監控複製代理和延遲

最適合

  • 將資料分發到多個報表伺服器
  • 具有報告工作負載的讀取規模場景
  • 將部分資料分發到遠端站點
  • 來自多個來源的資料整合
  • 偶爾會遇到連線場景(合併複製)
  • 在災後復原戰略中發揮輔助作用

優點

  • 對複製資料進行精細控制
  • 支援多個訂閱者
  • 靈活的拓撲結構選項
  • 可以複製特定的表或列
  • 過濾可以減少網路流量
  • 支援異構複製(SQL Server 至 Oracle)
  • 適用於標準版

缺點

  • 無自動故障轉移功能
  • 複雜配置和管理
  • 複製衝突的可能性(合併和點對點)
  • 資料同步延遲
  • 架構變更需要精心協調
  • 並非設計為主要HA解決方案
  • 故障排除可能充滿挑戰
  • 點對點通訊需要企業版

參考

8. 原木運輸

日誌傳送透過自動化的交易日誌備份、複製和復原流程,提供熱備災難復原和高可用性解決方案,簡單易用且可靠。ost-維護同步輔助資料庫的有效方法。

ACEWAY 的 SQL Server 日誌傳送

產品特色

  • 透過 SQL Agent 實現自動備份、複製和還原作業
  • 支援多個輔助伺服器
  • 可設定的備份和復原間隔
  • 待機模式允許對輔助驅動器進行唯讀存取。
  • 延遲日誌復原以保護錯誤復原功能
  • 用於集中監控的監控伺服器
  • 交易日誌壓縮支援

實施步驟

  • 確保主資料庫使用完整復原模式
  • 建立主資料庫的完整備份
  • 使用 NORECOVERY 選項在輔助伺服器上還原備份
  • 在主資料庫上配置日誌傳送
  • 指定所有伺服器均可存取的共用備份資料夾
  • 在主伺服器上設定備份作業計劃
  • 在輔助伺服器上設定複製和還原作業
  • (可選)配置監控伺服器
  • 測試故障轉移程序

最適合

  • Cost有效的災難復原解決方案
  • 擁有標準版授權的組織
  • 能夠容忍數分鐘資料遺失的方案
  • 能夠適應手動故障轉移的環境
  • 延遲恢復以滿足錯誤保護需求
  • 使用備用模式報告工作負載
  • 簡單的災難復原需求,無需複雜的基礎設施

優點

  • 配置和操作簡單
  • 低cost (標準版支援)
  • 支援多個輔助伺服器
  • 可設定的延遲可防止邏輯錯誤
  • 待機模式下的唯讀報告
  • 能夠容忍較高的網路延遲
  • 對主伺服器的影響極小
  • 成熟可靠的技術

缺點

  • 無自動故障轉移功能
  • 必須為每個資料庫單獨配置
  • 同步延遲(分鐘到小時)
  • 依備份間隔可能出現資料遺失
  • 手動故障轉移會增加復原時間目標 (RTO)。
  • 要求 SQL Server 代理程式在所有伺服器上運行
  • 日誌復原期間無法存取輔助資料庫
  • 應用程式在故障轉移後需要更改連接字串。

參考

9. 資料庫鏡像

資料庫鏡像是一種已棄用的資料庫級高可用性解決方案,自那時起未獲得任何增強。 SQL Server 2012 年版本雖然仍然可用,但微軟強烈建議所有新部署都遷移到 Always On 可用性群組。

ACEWAY 的 SQL Server 數據庫鏡像

產品特色

  • 主伺服器和鏡像伺服器架構
  • 用於自動故障轉移的可選見證伺服器
  • 兩種運作模式:高安全性和高效能
  • 支援同步和非同步操作
  • 自動頁面修復功能
  • 資料庫級保護
  • 支援資料傳輸加密

實施步驟

  • 確保資料庫使用完整復原模式
  • 建立完整備份並將其還原到鏡像伺服器,不啟用復原功能
  • 在主體和鏡像上建立鏡像端點
  • 配置用於身份驗證的憑證
  • 在伺服器之間建立鏡像會話
  • 可選擇配置見證伺服器以實現自動故障轉移。
  • 設定運作模式(高安全模式或高效能模式)
  • 測試故障轉移程序

最適合

  • 已在使用資料庫鏡像的遺留系統
  • 在遷移完成之前,將保留現有配置。
  • 不建議使用其他方案(該功能已棄用)

優點

  • 在高安全模式下,快速自動故障轉移並有見證人
  • 高安全模式下零資料遺失
  • 來自合作夥伴的自動頁面修復
  • 比單一資料庫的可用性組更簡單
  • 支援傳輸加密
  • 滾動升級,最大限度減少停機時間

缺點

  • 已棄用 SQL Server 2012(可能已刪除)
  • 每個資料庫的配置和故障轉移
  • 無可讀鏡面(無讀取刻度功能)
  • 每個資料庫獨立發生故障轉移
  • 故障轉移後需要更新連接字串
  • 僅限兩台伺服器(主伺服器和鏡像伺服器)
  • 沒有改進或新增功能
  • 微軟建議遷移到 Always On 可用性群組。

參考

10. 託管執行個體連結

託管實例連結在兩者之間建立混合連接 SQL Server 以及使用分散式可用性群組技術的 Azure SQL 託管實例,可實現近乎即時的資料複製,適用於災難復原、遷移和雲端整合場景。

ACEWAY 的 SQL Server 託管執行個體連結

產品特色

  • 利用分散式 AG 技術實現近實時複製
  • 單向複製(SQL Server 2016-2019 年(至 Azure)
  • 雙向複製帶故障恢復(SQL Server 2022 +)
  • 每個連結對應一個資料庫(支援多個連結)
  • Azure SQL 託管執行個體上的可讀副本
  • 免許可被動式災難復原副本選項
  • 線上遷移,停機時間最短

實施步驟

  • Prepare SQL Server 環境(VPN 或 ExpressRoute 到 Azure)
  • 配置 Azure SQL 託管執行個體
  • 啟用“始終開啟 AG”功能 SQL Server
  • 建立資料庫鏡像端點
  • 交換證書 SQL Server 和 MI
  • 使用 SSMS 或腳本建立託管實例鏈接
  • 驗證複製和同步
  • 如果用於讀取縮放,請設定唯讀路由。
  • 測試故障轉移程序

最適合

  • 採用基於雲端的備用方案的混合災難復原
  • 線上遷移到 Azure SQL 託管執行個體
  • 將分析和報告工作卸載到 Azure
  • 採用混合雲策略的組織
  • 需要 Azure 服務整合的場景
  • Cost 利用免許可被動式災難復原進行最佳化

優點

  • Most 高效率、停機時間最短的 Azure 遷移
  • 真正實現向業務關鍵層級的線上遷移
  • 雙向故障轉移 SQL Server 2022+
  • 免許可被動式災難復原副本降低了 costs
  • 與 Azure 服務集成,無需完全遷移
  • 使用 Azure 副本的讀取擴充功能
  • Azure 端的自動備份
  • 地理分佈到 Azure 區域

缺點

  • 每個連結只能使用一個資料庫
  • 不能與 MI 上的故障轉移組一起使用
  • 系統資料庫未複製
  • 實例級物件需要手動同步
  • SQL Server 2016-2019年單向傳輸(無故障恢復)
  • Azure cost託管執行個體
  • 網路連線需求(VPN/ExpressRoute)
  • 功能限制(不支援文件表、文件流)

參考

11. 高可用性解決方案比較

11.1 功能對比表

獨特之處 Always On AG 含有AG 分散式農業 FCI 複製 日誌傳送 鏡像 小米連結
Ent/Std Ent/Std 耳鼻喉科 Ent/Std Ent/Std Ent/Std Ent/Std Ent/Std
防護等級 數據庫 資料庫執行個體 數據庫 看板 資料庫/對象 數據庫 數據庫 數據庫
數據同步 同步/異步 同步/異步 同步/異步 共享 異步 異步 同步/異步 異步
自動故障轉移 可以 可以 可以 可以 沒有 沒有 可以 沒有
讀取標尺 可以 可以 可以 沒有 可以 有限 沒有 可以
RTO 分鐘 手動操作 手動操作 手動操作
RPO 零/分鐘 零/分鐘 零/分鐘 最小 分鐘 零/分鐘 最小
支援狀態 活躍 活躍 活躍 活躍 活躍 活躍 已過時 活躍

11.2 選擇HA解決方案

選擇解決方案時,請考慮以下因素:

  • 預算因素對解決方案選擇有顯著影響:企業版要求會影響授權協議。ost而基礎設施需求則因 FCI 的昂貴共享儲存和可用性群組的通用伺服器而異。
  • 複雜程度差異很大:日誌傳送的實作最為簡單,而分散式可用性群組則需要豐富的專業知識。
  • 恢復時間目標 (RTO) 要求決定了技術選擇。秒級停機時間要求採用始終在線的可用性群組或功能配置介面 (FCI),並具備自動故障轉移功能。分鐘級的停機時間容錯率則允許採用手動故障轉移解決方案,例如日誌傳送。
  • RPO 需求同樣重要:零資料遺失要求同步解決方案,而分鐘級容差則允許日誌傳送。
  • 基礎設施限制、讀取規模需求、地理分佈需求和雲端混合場景都會影響最佳解決方案的選擇。

12. 最佳實踐 SQL Server 高可用性

12.1 規劃與設計

透過對每個資料庫進行細緻的復原時間目標 (RTO) 和復原點目標 (RPO) 分析,評估業務需求。選擇符合需求的合適解決方案,而不是預設採用現有方案。ost 提供完善的方案。採用分層方法,規劃本地高可用性和異地災難復原。全面記錄架構,包括網路圖、故障轉移流程和復原手冊。

12.2 實施指南

透過定期測試和模擬故障,定期測試故障轉移程序,以驗證其有效性。 SQL Server 高可用性解決方案和團隊準備。持續監控運作狀況和效能。 SQL Server內建工具,例如 SQL Server 輪廓 以及動態管理視圖 (DMV)。配置針對同步延遲、故障轉移事件和健康狀況下降的全面警報。維護 SQL Server 備份策略 儘管實施了高可用性 (HA) 系統,但備份仍然是防止邏輯損壞和意外刪除的最後一道防線。務必使用累積更新、安全性修補程式和韌體更新來保持系統最新狀態。定期透過實際還原和應用程式測試來驗證復原流程,並了解如何處理以下情況: 資料庫卡在復原模式.

12.3 監控與維護

使用類似的工具 SQL Server 活動監視器, SQL Server 性能監視器以及用於健康監控和運行的動態管理視圖 DBCC 檢查數據庫 定期驗證資料庫完整性。利用 Always On 控制面板直觀地評估可用性組的運作狀況。密切監控同步延遲,特別是非同步副本和日誌傳送的延遲。使用以下工具仔細追蹤故障轉移事件: SQL Server 擴展活動 並分析模式背後的原因。建立正常運作的效能基準,並監控偏差,以發現潛在問題。定期進行容量規劃審查,確保基礎設施能夠支援不斷增長的工作負載。

13。 常問問題

Q:高可用性和災難復原之間有什麼區別? SQL Server?

答:高可用性可最大限度地減少資料中心內局部故障造成的停機時間,通常採用自動故障轉移,恢復時間目標 (RTO) 可在幾秒鐘或幾分鐘內實現。災難復原則可抵禦區域性災難,通常採用手動故障轉移,RTO 時間較長,但能涵蓋影響整個設施的事件。

Q:高可用性 (HA) 解決方案和讀取擴充解決方案之間有什麼區別?

答:高可用性解決方案確保資料庫在故障期間仍可訪問,並專注於正常運行時間和自動故障轉移功能。讀取擴展解決方案透過將唯讀工作負載分佈到多個資料庫副本上來提高查詢效能,專注於吞吐量和回應時間。雖然它們服務於不同的目的,但像 Always On 可用性群組這樣的同一項技術可以同時提供這兩種優勢:可讀輔助副本提供讀取擴充功能,同時也可用作故障轉移。 tar獲得高可用性。

問:哪個 SQL Server 高可用性解決方案最符合我的需求?

答:最佳解決方案取決於RTO和RPO。 tar獲得預算、版本可用性、基礎設施和專業知識。 Always On Availability Groups 適合我ost 企業級場景,而日誌傳送則適用於 cost對環境要求敏感。請對照對照表評估相關要求。

Q:Always On 可用性群組是否需要企業版?

答:標準版支援基本可用性群組,但有許多限制:每個群組只能有一個資料庫、一個輔助副本,且輔助副本無法讀取。要實現包括多個資料庫、八個輔助副本和可讀副本的完整功能,需要企業版。

Q:我可以使用日誌傳送嗎? SQL Server 標準版?

答:是的,標準版完全支援日誌傳輸,這使其成為一個極具吸引力的功能。ost- 為沒有企業版授權的組織提供有效的災難復原解決方案。

Q:Always On可用性群組和資料庫鏡像之間有什麼區別?

答:資料庫鏡像功能已棄用,它在單一資料庫層級運行,不提供可讀的輔助存取權限。 Always On 可用性群組支援資料庫群組,最多支援八個輔助資料庫,提供可讀副本和增強的監控功能。微軟建議遷移到 Always On。

Q:如何選擇故障轉移叢集執行個體和可用性群組?

答:選擇功能集配置項目 (FCI) 可實現實例級保護並利用共用儲存基礎架構。選擇可用性群組 (Ag) 可實現資料庫級保護、讀取擴充能力和地理分佈,但無需共用儲存。企業通常會將兩者結合使用,以獲得更全面的保護。

Q:我可以合併多個嗎? SQL Server 高可用性解決方案?

答:是的,組合使用多種解決方案很常見。 FCI 可以作為可用性群組的副本,提供執行個體級本地高可用性和資料庫級異地災難復原。日誌傳送可以作為可用性群組的補充,提供額外的遠端保護。務必徹底測試組合配置。

Q:同步複製和非同步複製有什麼不同?

答:同步複製在提交之前會等待輔助副本的確認,從而確保零資料遺失,但可能會引入延遲。非同步複製則無需等待即可進行,優化了效能,但在故障轉移期間可能會造成資料遺失。

Q:如果我已經有備份,我還需要備份了嗎? SQL Server 高可用性配置完成了嗎?

答:絕對可以。高可用性可以防止硬體故障,但無法防止邏輯損壞、意外刪除或惡意操作(這些操作會複製到所有副本)。備份對於時間點復原和合規性要求仍然至關重要。

Q:如果我已經有備份,我還需要備份了嗎? SQL Server 高可用性配置完成了嗎?

答:絕對可以。高可用性可以防止硬體故障,但無法防止資料庫損壞、意外刪除或惡意操作。備份對於時間點復原和合規性要求仍然至關重要。如果資料庫檔案損壞,且備份不可用或也已損壞,則需要使用專門的備份方案。 SQL資料庫修復軟體 可以協助從損壞的 MDF、NDF 和備份檔案中復原資料。

Q:什麼是包含可用性群組?它與普通可用性組有何不同?

A:包含可用性群組,於 SQL Server 2022 版會自動同步實例級對象,例如登入資訊、作業和元資料。常規可用性群組僅同步資料庫對象,實例對象需要手動複製。

問:我能否複製來自的數據? SQL Server 到 Azure SQL 託管執行個體?

答:是的,託管實例連結提供混合複製功能。 SQL Server 和蔚藍。 SQL Server 2016-2019 年支持單向複製,而 SQL Server 2022+ 支援雙向複製和故障恢復,適用於災難復原、遷移和混合場景。

Q:會發生什麼事? SQL Server 故障轉移期間的代理任務?

答:使用傳統可用性群組時,必須在輔助副本上手動建立作業。包含可用性群組(SQL Server 2022 年及以後版本)會自動同步作業。故障轉移叢集實例將作業包含在實例級保護範圍內。

14. 結論

SQL Server 提供全面的高可用性解決方案,滿足從部門資料庫到關鍵任務型企業系統的各種需求。每種解決方案都有獨特的功能和優缺點,資料庫管理員必須了解這些優缺點才能做出明智的決策。

Always On 可用性群組是現代部署的旗艦技術,其中包含可用性群組簡化了管理,分散式可用性群組則支援複雜的跨平台場景。故障轉移群集實例繼續滿足實例級保護需求,而日誌傳送對於 c 仍然至關重要。ost敏感場景。託管實例連結開啟了雲端混合部署的可能性,連接了本地環境。 SQL Server 使用 Azure。

根據具體業務需求來配對解決方案是成功的關鍵因素。沒有一成不變的方案。企業必須仔細評估復原時間目標 (RTO) 和復原點目標 (RPO) 要求、預算限制、基礎設施能力和管理經驗。通常,最佳架構會結合多種解決方案,以實現全面保護。請考慮您的高可用性 (HA) 策略如何與更廣泛的雲端採用計劃相協調,並參考相關文章以獲得詳細的實施指導,以確保您的成功。 SQL Server 基礎設施能夠提供您的業務所需的可靠性。


關於作者

元盛 是一位資深資料庫管理員 (DBA),擁有超過 10 年的 SQL Server 環境和企業資料庫管理。他成功解決了金融服務、醫療保健和製造業等行業的數百個資料庫恢復場景。

袁專長於 SQL Server 資料庫復原、高可用性解決方案和效能優化。他擁有豐富的實務經驗,包括管理多TB資料庫、實施Always On可用性群組以及為關鍵業務系統開發自動備份和復原策略。

透過他的技術專長和實踐方法,袁致力於創建全面的指南,幫助資料庫管理員和 IT 專業人員解決複雜的 SQL Server 高效應對挑戰。他始終掌握最新 SQL Server 版本和微軟不斷發展的資料庫技術,定期測試恢復場景以確保他的建議反映現實世界的最佳實踐。

有關於的問題 SQL Server 恢復或需要額外的資料庫故障排除指導?袁歡迎 回饋和建議 用於改進這些技術資源。

立即分享: