1. 簡介 SQL Server 始終開啟
1.1 什麼是 SQL Server 始終開啟？
SQL Server Always On 是微軟推出的全面高可用性和災難復原解決方案，該方案於 2019 年推出。 SQL Server 2012 年。它代表著對資料庫鏡像和日誌傳送等先前技術的重大進步，確保了對資料的持續訪問，同時最大限度地減少了停機時間和資料遺失。
1.2 企業為何需要始終在線的解決方案
在當今的數位經濟中，資料庫停機時間直接轉化為…ost 收入損失、聲譽受損和監管合規問題。企業需要高可用性解決方案，以確保近乎持續的正常運作時間，同時抵禦各種故障狀況。
傳統的備份和復原流程已無法滿足現代企業的需求。當關鍵資料庫發生故障時，企業無法承受從備份還原所需的數小時時間。 Always On 解決方案提供自動故障轉移功能，可在數秒或數分鐘內恢復服務，而非數小時，從而顯著降低系統故障的影響。
除了基本可用性之外，企業還需要將讀取密集型工作負載從生產資料庫卸載，在不停機的情況下執行維護，並防止站點級災難。 SQL Server Always On 透過統一的架構滿足所有這些要求，該架構可以從小型部署擴展到全球分散式系統。
1.3 關鍵概念：RTO、RPO、HA 與 DR
復原時間目標 (RTO) 定義了故障發生後可接受的最大停機時間—資料庫必須多快恢復上線。
復原點目標 (RPO) 定義了以時間為單位的最大可接受資料遺失量－企業能夠承受遺失多少近期提交的資料。
高可用性 (HA) 專注於最大限度地減少同一資料中心內因硬體故障或軟體崩潰等常規故障造成的停機時間。
災難復原 (DR) 災難復原 (DR) 旨在應對影響整個站點的災難性事件，並在地理位置不同的位置維護資料副本。高可用性 (HA) 著重於最大限度地減少停機時間，而災難復原 (DR) 則著重於確保在重大事件期間的資料保護和業務連續性。
SQL Server Always On 在單一統一架構中同時支援高可用性 (HA) 和災難復原 (DR)。同步提交模式可實現 RPO = 0，並可透過自動故障轉移實現接近零的恢復時間目標 (RTO)；非同步提交模式可接受潛在的資料遺失，以換取更低的遠端站點延遲影響。
1.4 始終在線的解決方案
SQL Server Always On 提供三種部署選項，每種選項都適用於不同的可用性和基礎架構要求。本指南涵蓋所有三種選項：
- Always On 可用性小組 (AG)： 無需共用儲存即可實現資料庫級高可用性和災難復原。
- Always On 故障轉移叢集實例 (FCI)： 利用共用儲存實作實例級高可用性。
- AG + FCI 組合： 結合實例級和資料庫級故障轉移的雙層保護，實現最大程度的復原能力。
2. Always On 可用性組
Always On 可用性組 (AG) 是一個資料庫層級的高可用性和災難復原解決方案，它透過連續交易日誌傳送將一組使用者資料庫複製到最多八個輔助副本。
2.1主要功能
- 資料庫層級故障轉移：單一資料庫或資料庫群組可以獨立於其他因素發生故障轉移。 SQL Server 實例;
- 企業版最多支援 9 個副本（1 個主副本，8 個輔助副本）；
- 同步提交模式可實現零資料遺失；非同步提交模式適用於遠端災難復原副本；
- 當主節點不可用時，同步副本會自動故障轉移；
- 用於卸載報表和備份工作負載的可讀輔助副本；
- 可用性群組監聽器提供一個單一的連線端點，該端點會自動路由到目前主節點。
2.2 實施步驟
- 準備 Active Directory 服務帳戶並配置所有節點上的權限；
- 在所有參與伺服器上安裝並驗證 Windows Server 故障轉移叢集；
- 安裝 SQL Server 在每個節點上作為獨立實例，使用一致的路徑和設定；
- 透過以下方式啟用「始終在線可用性群組」功能 SQL Server 配置管理器或 PowerShell；
- 將資料庫設定為完整復原模式，並進行完整備份和日誌備份；
- 建立可用性群組，新增副本，並配置可用性和故障轉移模式；
- 使用自動種子或手動備份和還原來為輔助副本添加種子；
- 建立可用性群組監聽器並驗證客戶端連線。
如需完整的逐步操作指南，請參閱我們的 始終在線可用性組完整指南.
2.3 最適合
- 需要零資料遺失和自動故障轉移的關鍵任務資料庫；
- 需要可讀輔助資料進行報告或備份卸載的工作負載；
- 跨多個站點的災難復原部署；
- 沒有現有共享儲存基礎架構的環境。
2.4個優點
- 無需共用儲存－每個副本都使用獨立的本機儲存；
- 在單一配置中同時支援高可用性和災難復原；
- 易於閱讀的輔助文件可以減輕主要文件的工作量；
- 資料庫層級的粒度允許為每個資料庫群組設定不同的故障轉移策略。
2.5個缺點
- 要獲得完整功能集，需要企業版（標準版支援基本 AG，但有許多限制）；
- 同步提交模式會增加與網路往返時間成正比的寫入延遲；
- 登入資訊、SQL Agent 作業和連結伺服器需要手動同步。 SQL Server 2019 年及以前；
- 所有副本必須位於相同 Windows Server 故障轉移叢集的節點上。
2.6參考
- 微軟官方文件： 什麼是 Always On 可用性群組？
- 微軟官方文件： 獲得 Started 與 Always On 可用性群組
3. Always On 故障轉移叢集實例
Always On 故障轉移叢集實例 (FCI) 透過運行單一實例提供實例級高可用性 SQL Server 此實例跨多個共享相同儲存的實體節點運行。當活動節點發生故障時， SQL Server 備用節點上的執行個體會自動恢復。tarted，使客戶端應用程式能夠透明地完成過渡。
3.1主要功能
- 實例層級故障轉移：執行個體上的所有資料庫作為一個整體一起發生故障轉移；
- 所有節點均可存取的共享儲存（儲存區域網路 (SAN)、iSCSI、儲存空間直連或 SMB）；
- 虛擬網路名稱和虛擬 IP 位址提供穩定的連線端點，無論哪個節點處於活動狀態；
- Windows Server故障轉移叢集管理節點運作狀況監控、仲裁和故障轉移編排；
- 支援主備、主主、N+1 和 N+M 節點配置類型。
3.2 實施步驟
- 為所有叢集節點配置和附加共用儲存；
- 安裝故障轉移群集功能並驗證叢集配置；
- 建立 Windows Server 故障轉移叢集並配置仲裁；
- 跑過 SQL Server 安裝時選擇故障轉移叢集選項，並指定虛擬網路名稱和共用儲存路徑；
- 在其中新增其他節點 SQL Server 故障轉移叢集實例；
- 透過測試節點間的手動故障轉移來驗證故障轉移行為。
如需完整的逐步操作指南，請參閱我們的 SQL Server 故障轉移集群完整指南.
3.3 最適合
- 具有現有共享儲存基礎設施（SAN 或 iSCSI）的環境；
- 需要實例級故障轉移且所有資料庫必須同時發生故障轉移的應用；
- 在客戶透明度至關重要且不允許應用程式端進行任何更改的情況下；
- 優先考慮單一實例故障轉移模型簡易性的組織。
3.4個優點
- 實例級自動故障轉移，無需客戶端重新配置；
- 無資料複製開銷－所有節點存取相同的儲存；
- 所有資料庫同時發生可預測的故障轉移行為；
- 支援靈活的節點配置（Active/Active、N+1、N+M），以優化硬體利用率。
3.5個缺點
- 除非儲存本身俱有冗餘性，否則共享儲存存在潛在的單點故障風險；
- 只有一個節點運行 SQL Server 同時進行－輔助節點上沒有讀取負載平衡；
- 不與可用性群組配合使用，則沒有內建的災難復原功能；
- 共享儲存基礎設施增加了 cost 與 AG 相比，其複雜性更高。
3.6參考
- 微軟官方文件： Always On 故障轉移叢集實例（SQL Server)
4. 將可用性群組與故障轉移群集實例結合使用
對於既需要實例級保護又需要資料庫級保護的組織而言， SQL Server 支援 host在故障轉移叢集執行個體 (FCI) 上部署可用性群組副本。在此配置中，每個 FCI 節點都充當單一可用性副本，因此 FCI 故障轉移對可用性群組是透明的，而可用性群組故障轉移則提供跨站點的資料庫層級保護。這種組合實現了…ost 提供全面的高可用性和災難復原保障 SQL Server.
4.1主要功能
- 兩層故障轉移：FCI 處理實例層級節點故障；AG 處理站點層級或副本層級故障；
- 無論 FCI 包含多少個節點，每個 FCI 在可用性群組中都算是副本；
- FCI-host依照標準 FCI 要求，ed 副本仍需要共用儲存；
- AG 複製品 hostFCI 僅支援手動故障轉移－FCI-h 不支援自動故障轉移。osted 複製品；
- 獨立實例可以與 FCI-h 一起參與同一個可用性群組。osted 複製品。
4.2 實施步驟
- 按照標準 FCI 設定程序，獨立部署和驗證每個 FCI；
- 確保所有 FCI 節點和獨立副本節點都屬於同一個 Windows Server 故障轉移叢集；
- 在每個 FCI 實例上啟用 Always On 可用性群組功能；
- 確認沒有單一 WSFC 節點會 host 在任何可能的 FCI 故障轉移後，同一可用性群組的兩個副本；
- 建立可用性群組，將 FCI 執行個體指定為副本，並為所有 FCI-h 配置手動故障轉移模式。osted 複製品；
- 初始化輔助副本並配置可用性群組監聽器。
有關 FCI 設定詳情，請參閱我們的 SQL Server 故障轉移集群完整指南。有關可用性群組 (AG) 設定的詳細信息，請參閱我們的 Always On 可用性群組完整指南。
4.3 最適合
- 需要防範單一節點故障和站點級災難的關鍵任務環境；
- 已經運行 FCI 且需要新增跨站點災難復原功能的組織；
- 受監管行業，其中最高級別的資料保護和可用性服務水準協議是強制性的；
- 大規模部署中，實例級和資料庫級故障轉移策略必須共存。
4.4個優點
- 最大程度的保護：節點故障由 FCI 處理，站點故障由 AG 處理；
- FCI 故障轉移對可用性群組是透明的－可用性群組在 FCI 故障轉移期間看不到任何副本變更；
- 靈活拓樸：混合 FCI-host同一可用性群組中的 ed 副本和獨立副本。
4.5個缺點
- FCI-hosted 副本僅支援手動 AG 故障轉移－這些副本不支援自動 AG 故障轉移；
- 需要仔細規劃WSFC節點，以防止單一節點故障。ostFCI故障轉移後建立同一AG的兩個副本；
- 更高的基礎設施 cost 營運複雜度高於 AG 或 FCI 單獨營運的複雜度；
- 每個FCI組件仍然需要共用儲存空間。
4.6參考
- 微軟官方文件： 故障轉移叢集和 Always On 可用性群組 (SQL Server)
- 微軟官方文件： 什麼是 Always On 可用性群組？
- 微軟官方文件： 獲得 Started 與 Always On 可用性群組
- 微軟官方文件： Always On 故障轉移叢集實例（SQL Server)
5. 始終在線解決方案的比較
5.1 功能對比表
| 獨特之處 | 可用性組 | 故障轉移叢集實例 | AG + FCI 聯合 |
|---|---|---|---|
| 故障轉移範圍 | 資料庫級 | 實例級 | 任何一種 |
| 需要共享存儲 | 沒有 | 可以 | 是的（針對FCI元件） |
| 資料複製 | 每個副本的日誌記錄 | 無（共享儲存） | FCI之間的對數關係 |
| 自動故障轉移 | 是的（同步副本） | 可以 | FCI：是；AG：否 |
| 可讀的二級 | 可以 | 沒有 | 是的（農業部分） |
| 災難恢復 | 內建的 | 非內建 | 內建的 |
| 最大副本 | 9（企業） | 不適用 | 9（企業） |
| 基礎設施的複雜性 | 媒材 | 媒材 | 高 |
| 價格 | 較低（無需SAN） | 更高（需要SAN） | 最高 |
5.2 選擇您的始終在線解決方案
Star與您的存儲基礎架構配合使用：如果您沒有現有的共享存儲，可用性組是自然之選，並且ost cost-同時實現高可用性和災難復原的有效途徑。如果您已經執行SAN環境並且需要實例層級故障轉移，FCI是更簡單的選擇—但如果將來需要跨站點災難恢復，則需要計劃稍後新增AG。
只有當您確實需要兩層防護，並且具備應對日益複雜情況的運作成熟度時，才選擇 AG + FCI 組合。需要記住的關鍵限制是 FCI-hosted AG 副本不支援自動 AG 故障轉移，因此這種拓撲結構需要手動幹預才能實現可用性群組層級的故障轉移。
對於米ost 對於當今的全新部署，Always On Availability Groups 是推薦的解決方案。tar關鍵點：它同時涵蓋了高可用性和災難恢復，不需要共享存儲，並且支援可讀輔助存儲——這是 FCI 單獨無法比擬的功能。
6. 最佳實踐 SQL Server 始終在線解決方案
6.1 規劃與設計
- 在選擇始終在線解決方案之前，先明確 RTO 和 RPO 要求——這些 tar取得直接判斷同步提交模式或非同步提交模式合適，以及自動故障轉移是否可行。
- 調整輔助副本的大小，使其能夠在故障轉移事件期間處理主副本的全部工作負載，包括尖峰負載場景。
- 對於 AG 部署，同步副本應放置在同一資料中心或低延遲網路中，以最大程度地減少寫入延遲的影響。對於地理位置較遠的災難復原副本，則應保留非同步模式。
- 設計法定人數時，應使用奇數票。對於雙節點集群，添加文件共享或雲見證作為第三票，以防止腦裂情況的發生。
- 對於多子網路部署，請仔細規劃網路拓撲。每個子網路都需要自己的監聽器 IP 位址，客戶端需要在其連接字串中設定 MultiSubnetFailover=True。
6.2 實施指南
- 使用一致的 SQL Server 所有副本的版本、版本號碼和累積更新等級。混合的補丁等級可能會導致故障轉移期間出現意外行為。
- 配置專用的網路接口，用於叢集心跳流量，與應用程式流量分開。
- 啟用初始資料庫同步的自動種子數據 SQL Server 2016 年及以後版本－它消除了手動將備份複製到輔助副本的需要。ost 場景。
- 對於 AG + FCI 拓樸結構，每次 FCI 節點配置變更後，都要驗證是否存在單一 WSFC 節點最終處於 h 狀態的情況。ost建立同一可用性群組的兩個副本。
- 一律使用 SQL Server 使用 Management Studio 或 Transact-SQL 管理可用性群組故障轉移—切勿直接使用故障轉移叢集管理器，因為它不知道 AG 同步狀態，可能會導致長時間停機或資料遺失。
6.3 監控與維護
- 使用可用性群組儀表板定期監控同步運作狀況、傳送佇列和重做佇列。 SQL Server 管理工作室或動態管理視圖 (DMV)。輔助伺服器上不斷增長的重做佇列表示存在 I/O 瓶頸，這將延遲故障轉移復原。
- 在輔助副本上執行 DBCC CHECKDB，以將完整性檢查從主副本卸載。請參閱我們的 DBCC CHECKDB 指南 洽詢詳情。
- 在斷裂前， SQL Server 使用捲動升級進行修補程式：首先修補輔助副本，執行計畫內的手動故障轉移到已修補的輔助副本，然後再修補原主副本。這樣可以將停機時間限制在單次故障轉移的持續時間內。
- 定期在非生產環境中測試故障轉移。未經測試的自動故障轉移並非可靠的復原策略。
- 使用以下方式設定可用性群組運作狀況變更、副本角色轉換和同步故障的警報 SQL Server 代理或專用監控工具，例如 SQL Server 性能監視器.
7。 常問問題
問：什麼是 SQL Server 始終開啟？
A: SQL Server Always On 是微軟於 2019 年推出的高可用性和災難復原平台。 SQL Server 2012 年。它包含兩項技術——Always On 可用性群組和 Always On 故障轉移叢集實例——在硬體、軟體或網站發生故障時，可提供自動故障轉移、資料冗餘和對資料庫的持續存取。
Q：Always On可用性群組和故障轉移叢集實例之間有什麼區別？
答：可用性群組 (AG) 在資料庫層級運行，透過日誌傳送將資料複製到獨立的輔助副本，且不需要共用儲存。故障轉移叢集執行個體 (FCI) 在執行個體層級運行，需要所有節點均可存取的共用存儲，並將所有資料庫作為一個整體進行故障轉移。 AG 支援可讀輔助副本和內建災難復原功能；FCI 則不支援。
Q：Always On可用性群組需要共用儲存嗎？
答：不。每個可用性組副本都在本機儲存上維護各自獨立的資料庫副本。只有當您使用故障轉移群集實例來…時，才需要共用儲存。ost AG 復刻品。
Q：我可以使用 Always On 功能嗎？ SQL Server 標準版？
A: SQL Server 標準版支援基本可用性組tar與… SQL Server 2016 年版本，但有許多限制：每個可用性群組 (AG) 僅限一個資料庫，最多兩個副本，且不支援可讀輔助資料庫。標準版 FCI 不受這些限制。企業版則需要 Always On 的完整功能。
Q：可用性群組中最多可以有多少個副本？
A: SQL Server 企業版最多支援九個副本：一個主副本和八個輔助副本。分散式可用性群組可以將副本數量擴展到兩個獨立可用性群組的 18 個副本。
Q：FCI-h 可以嗎？osted 副本是否使用自動 AG 故障轉移？
答：不。當可用性副本處於高可用性狀態時，ost在故障轉移群集實例上，該副本不支援自動可用性群組故障轉移。所有涉及 FCI-h 的可用性組故障轉移。ost複製品需要人工幹預。
Q：同步提交模式和非同步提交模式有什麼不同？
答：同步提交模式要求主庫等待從庫完成日誌記錄的加固後再提交，從而確保零資料遺失（RPO = 0）。ost 增加寫入延遲。非同步提交模式允許主節點無需等待即可提交，從而降低延遲，但如果主節點在從節點接收到所有日誌記錄之前發生故障，則存在資料遺失的風險。本地高可用性副本應使用同步模式，遠端災難復原副本應使用非同步模式。
問：一個 SQL Server Always On 故障轉移方案？
答：在正常情況下，同步可用性群組副本的自動故障轉移通常會在 30 秒內完成。 FCI 故障轉移通常需要 20 到 60 秒，具體取決於資料庫復原時間。實際持續時間取決於工作負載、資料庫大小以及 WSFC 中配置的運行狀況檢查逾時設定。
Q：故障轉移期間客戶端連線會發生什麼情況？
答：發生故障轉移時，現有連線將被中斷。使用可用性群組偵聽器並包含連接重試邏輯的應用程式會在故障轉移完成後自動重新連接到新的主節點。在連線字串中新增 `MultiSubnetFailover=True` 可以提高多子網路部署中的重新連線速度。
Q：我該如何申請 SQL Server 在始終在線的環境下，如何以最小的停機時間完成修補程式？
答：採用捲動升級：先修補備用副本，然後執行計畫內的手動故障轉移到已修補的備用副本，最後修補原主副本。這樣可以將停機時間限制在單次計畫故障轉移的持續時間內—通常不到一分鐘。
Q：我可以將 Always On 可用性群組與故障轉移叢集實例結合使用嗎？
A：是的。你可以…ost 在 FCI 執行個體上部署 AG 副本，以實現執行個體級和資料庫級故障轉移保護。每個 FCI 算一個 AG 副本。這種拓樸結構需要仔細規劃 WSFC 節點，以確保沒有單一節點發生故障。ost在任何可能的 FCI 故障轉移之後，都會出現同一 AG 的兩個副本。
Q：如果我的資料庫在 Always On 環境中損壞，我該怎麼辦？
答：首先，檢查損壞是存在於所有副本還是僅存在於主副本。如果存在健康的備用副本，請立即故障轉移到該備用副本。如果所有副本都存在損壞，請從乾淨的備份中還原。定期在備用副本上執行 DBCC CHECKDB 命令，以便及早發現損壞。如果備份也受到影響，則需要進行專門的故障轉移。 SQL Server 數據恢復工具 作為最後的手段，可以嘗試從損壞的 MDF 檔案中提取資料。
Q：Always On 可用性群組與舊版本相比有何不同？ SQL Server HA解決方案？
A：AG取代了以下舊技術： 原木運輸 以及 複製日誌傳送需要手動故障轉移，且不具備自動角色轉換功能；複製的設計目標是資料分發而非高可用性。 AG 提供自動故障轉移、同步提交實現零資料遺失以及可讀的輔助副本——這些都是上述技術無法比擬的。
8. 結論
SQL Server Always On 提供了一個靈活的企業級平台，用於實現高可用性和災難復原。 Always On Availability Groups 是 m 的理想選擇。ost 現代部署：它無需共享存儲，支援可讀輔助存儲，並在單一配置中同時處理本地高可用性和跨站點災難恢復。當實例級故障轉移和現有共享儲存基礎架構是主要需求時，故障轉移叢集執行個體仍然是可靠的選擇。結合這兩種技術可提供最全面的保護—在關鍵時刻。ost 基礎建設投資更大，營運更複雜。
無論選擇哪種解決方案，基本原理都相同：首先定義您的復原時間目標 (RTO) 和復原點目標 (RPO) 要求，然後圍繞這些要求設計拓撲結構。 tar定期取得並測試故障轉移方案。一個經過充分測試且部署完善的 Always On 解決方案，能夠在生產環境發生故障時實現可預測的復原。
關於作者
元盛 是一位資深資料庫管理員 (DBA)，擁有超過 10 年的 SQL Server 環境和企業資料庫管理。他成功解決了金融服務、醫療保健和製造業等行業的數百個資料庫恢復場景。
袁專長於 SQL Server 資料庫復原、高可用性解決方案和效能優化。他擁有豐富的實務經驗，包括管理多TB資料庫、實施Always On可用性群組以及為關鍵業務系統開發自動備份和復原策略。
透過他的技術專長和實踐方法，袁致力於創建全面的指南，幫助資料庫管理員和 IT 專業人員解決複雜的 SQL Server 高效應對挑戰。他始終掌握最新 SQL Server 版本和微軟不斷發展的資料庫技術，定期測試恢復場景以確保他的建議反映現實世界的最佳實踐。
有關於的問題 SQL Server 恢復或需要額外的資料庫故障排除指導？袁歡迎 回饋和建議 用於改進這些技術資源。