SQL Server Always On 可用性小組：完整指南 [2026]

1. 了解 Always On 可用性組

1.1 它是什麼以及它是如何運作的

Always On 可用性小組 (AG) 是一種 SQL Server 企業 高可用性 這是一種在資料庫層級運行的災難復原解決方案。可用性群組將一個或多個使用者資料庫組合成一個故障轉移單元，並透過連續交易日誌傳送將其複製到最多八個輔助副本。當主副本發生故障時，指定的同步輔助副本會自動接管，無需共用儲存或人工幹預，即可在幾秒鐘內恢復存取。

1.2 Always On 可用性群組與故障轉移叢集實例

SQL Server Always On 包含兩種不同的技術：可用性群組 (AG) 和故障轉移叢集實例 (FCI)：

	始終在線可用性組	Always On 故障轉移叢集實例
故障轉移範圍	資料庫級	實例級（所有資料庫同時故障轉移）
資料複製	基於日誌的複製到每個輔助節點	無 — 所有節點共用相同儲存空間
共享存儲	不需要	必需（儲存區域網路 (SAN)、iSCSI、S2D 或 SMB）
可讀的二級	可以	沒有
災難恢復	內建（跨站點非同步副本）	不與 AG 配對則無法內建。

何時使用： 當您需要執行個體級故障轉移且已有共用儲存基礎架構時，請使用 FCI。當您需要資料庫層級粒度、可讀輔助儲存或災難復原時，請使用 AG。對於 most 全面保護，將兩者結合起來：將每個副本作為 FCI 節點運行，並將它們連結成一個 AG。

1.3 優點和局限性

為妳而設的優點:

• 同步副本自動故障轉移，復原時間目標 (RTO) 接近零；
• 同步提交模式下零資料遺失（恢復點目標 (RPO) = 0）；
• 無需共用儲存－每個副本都使用獨立的本機儲存；
• 可讀的輔助儲存設備可以減輕主儲存設備的報表和備份工作負載；
• 在單一配置中同時支援本地高可用性 (HA) 和跨站點災難復原 (DR)。

限制：

• 需要在所有副本上啟用 Windows Server 故障轉移叢集；
• 企業版提供完整功能集（標準版支援基本 AG，但有許多限制）；
• 同步提交模式會增加寫入作業的延遲，延遲時間與網路往返時間成正比；
• 登入資訊、SQL Agent 作業和連結伺服器不會自動同步。 SQL Server 2019 年及更早（已解決） SQL Server 2022 年包含可用性組）。

2. Always On 可用性群組架構

2.1 核心組成部分與概念

2.1.1 可用性資料庫

可用性資料庫是參與可用性群組的使用者資料庫。這些資料庫必須滿足特定要求：它們必須使用完整復原模式，擁有完整備份，並且在新增至可用性群組之前必須存在於主副本上。

當資料庫加入可用性群組時，它就成為一個同步集合的一部分，該集合可以作為一個整體進行故障轉移。可用性群組中的所有資料庫共用相同的故障轉移狀態，這表示如果主副本發生故障，所有資料庫將同時故障轉移到同一個輔助副本。這確保了依賴多個相關資料庫的應用程式的一致性。

2.1.2 可用性副本

可用性副本是 SQL Server 實例ost 可用性群組包含多個資料庫副本。每個副本都維護資料庫的實體副本，並透過交易日誌記錄傳送進行同步。一個可用性群組最多可以包含九個副本：一個主副本和最多八個輔助副本。

2.1.3 主副本

主副本 host這是可用性資料庫的讀寫副本。所有資料修改（INSERT、UPDATE、DELETE）都在主副本上進行。客戶端應用程式連接到主副本以執行所有寫入操作，預設情況下，讀取操作也連接到主副本。

2.1.4 二級副本

二級副本 host 可用性資料庫的唯讀副本透過持續應用從主副本接收的交易日誌記錄來維護。每個輔助副本接收、強化並套用日誌記錄，以保持其資料庫副本與主副本同步。

2.2 可用性模式

2.2.1 同步提交模式

同步提交模式透過要求主副本在提交交易之前等待輔助副本確認交易日誌記錄已加固，從而提供零資料遺失保護。此模式對於資料遺失不可接受的高可用性配置至關重要。

2.2.2 非同步提交模式

非同步提交模式優先考慮主副本的效能，允許交易在無需等待輔助副本確認日誌加固的情況下提交。此模式適用於災難復原副本，或當網路延遲導致同步提交不切實際時。

這種方式的弊端在於故障轉移期間可能存在資料遺失。如果主副本發生故障，某些已提交的交易可能無法到達備用副本。潛在的資料遺失量取決於網路頻寬、備用副本效能以及故障發生的時間。組織在使用非同步模式時必須接受這種風險。

2.3 故障轉移類型

2.3.1 自動故障轉移

自動故障轉移功能可讓可用性群組偵測到主副本故障，並在無需管理員介入的情況下自動將輔助副本提升為主副本。此功能消除了對故障進行人工回應的需求，從而最大限度地縮短了恢復時間目標 (RTO)。

自動故障轉移需要同步提交模式以確保零資料遺失。啟用後，可用性群組會持續監控主副本的運作狀況。如果主副本沒有回應或發生故障，Windows Server 故障轉移叢集將自動故障轉移到指定的輔助副本。

2.3.2 手動故障轉移

手動故障轉移允許管理員有意地將主副本角色切換到輔助副本，通常用於計劃內維護或測試。與自動故障轉移不同，手動故障轉移需要管理員明確執行操作才能啟動。

對於同步提交副本，支援無資料遺失的手動故障轉移。管理員透過以下方式發起故障轉移： SQL Server Management Studio、Transact-SQL 或 PowerShell。主副本完成目前交易的處理後，會將所有剩餘的日誌記錄傳送到… tar取得次要角色，並等待確認後再轉移主要角色。

非同步提交副本也可以進行手動故障轉移，但這需要強制故障轉移，可能會導致資料遺失。管理員應僅在實際災難情況下，且主副本不可用，且與長時間停機相比，資料遺失是可以接受的時，才使用強製手動故障轉移。

2.3.3 強制故障轉移

強制故障轉移允許故障轉移到非同步輔助副本或未完全同步的輔助副本，但會明確告知使用者可能存在資料遺失。此選項作為最後的手段，用於主副本不可用且不存在同步的輔助副本的情況。

2.4 資料同步

2.4.1 資料同步的工作原理

Always On 可用性群組的資料同步是透過將交易日誌記錄從主副本持續傳輸到所有輔助副本來實現的。這種基於日誌的同步方式既保證了資料的一致性，也允許每個副本擁有獨立的儲存空間。

2.4.2 事務日誌記錄和加固

交易日誌加固是關鍵步驟，它將日誌記錄寫入輔助副本上的持久性儲存。加固可確保日誌記錄在輔助副本發生故障時仍存在，並可在復原期間重播。

2.5 讀取規模和可讀取的二級副本

2.5.1 卸載唯讀工作負載

可讀輔助副本使組織能夠將讀取密集型工作負載從主副本卸載，從而提高整體系統效能和資源利用率。這種讀取擴充能力是可用性群組相對於舊式高可用性解決方案的關鍵優勢之一。

組織在設計可用性群組配置時應考慮唯讀工作負載需求。多個可讀輔助伺服器可以將報告負載分散到多個伺服器。只讀路由清單定義了輔助伺服器接收讀取意圖連接的順序，從而實現負載平衡策略。

2.5.2 輔助副本上的備份作業

在輔助副本上執行備份可以降低主副本的輸入/輸出 (I/O) 和中央處理器 (CPU) 負載，使其能夠專注於事務性工作負載。此功能有助於組織在不影響生產效能的前提下滿足備份需求。

SQL Server 支援在輔助副本上進行完整資料庫備份、差異備份和交易日誌備份。備份首選項可以設定為優先使用輔助副本、優先使用主副本、僅使用輔助副本或使用任意副本。備份系統會根據這些首選項和目前可用性自動選擇合適的副本。

有關更多詳細信息 SQL Server 備份，請參閱我們的 綜合指南.

2.6 可用性組監聽器

2.6.1 什麼是監聽器？

可用性群組偵聽器是一個虛擬網路名稱 (VNN) 和 IP 位址，用戶端應用程式使用它來連接到可用性群組資料庫。偵聽器會自動將連線重新導向至目前主副本，因此無需應用程式追蹤哪個伺服器目前是主伺服器。

2.6.2 用戶端連接路由

客戶端連接路由透過監聽器支援讀寫和只讀連接意圖。監聽器會檢查連接請求，並根據應用程式的意圖將其路由到相應的副本。

3. 先決條件和要求

3.1 Windows Server 可用性群組的故障轉移叢集

3.1.1 Windows Server故障轉移群集基礎知識

Windows Server故障轉移叢集 (WSFC) 透過管理叢集成員、運作狀況監視和故障轉移編排，為 Always On 可用性群組奠定了基礎。與故障轉移群集實例不同，可用性群組僅使用 WSFC 進行群集協調，而不用於共用儲存管理。

每 SQL Server 參與可用性群組的執行個體必須是 WSFC 叢集中的一個節點。此叢集負責管理仲裁投票、節點健康檢測和可用性群組資源狀態。當主副本發生故障時，WSFC 會協調故障轉移流程，並更新叢集資源以反映新的主副本。

3.1.2 集群仲裁配置

叢集法定人數決定了網路連線出現問題時哪些節點可以運行，從而防止出現多個節點各自獨立聲稱自己是主節點的腦裂情況。法定人數配置定義了群集決策中多數投票的條件。

可用性組有多種法定人數模式可供選擇：

• 節點多數制僅使用叢集節點投票，並且適用於節點數為奇數的叢集。
• 節點和檔案共享多數投票功能增加了一個檔案共享見證投票，適用於偶數節點叢集。
• 節點和磁碟多數模式使用磁碟見證，但對於可用性群組來說不太常見，因為不需要共用儲存。

3.1.3 多子網路聚類

多子網路叢集使可用性群組副本能夠跨越不同的網路子網，從而支援跨資料中心的地理分散式部署。對於副本位於不同位置的災難復原配置而言，此功能至關重要。

3.2 SQL Server 版本要求

3.2.1 企業版功能

SQL Server 企業版提供完整的可用性群組功能，沒有任何限制。企業版支援最多八個輔助副本、可讀輔助副本、自動種子資料、分散式可用性群組以及所有進階功能。

3.2.2 標準版功能（基本可用性組）

SQL Server 2016 標準版及更高版本對基本可用性群組 (BAG) 的支援有許多限制。基本可用性組以較低的成本提供核心高可用性功能。ost適用於需求較簡單的組織。

4. 設定 Always On 可用性群組

4.1 環境準備

在建立可用性群組之前，必須正確準備環境，包括 Active Directory 帳戶、伺服器設定和網路基礎架構。

4.1.1 網域控制器設定

必須配置 Active Directory 網域控制站以支援可用性群組集，且 SQL Server 服務帳戶。

1. 使用網域管理員憑證登入網域控制器。
2. 未結案工單 服務器管理器 並導航到 工具 -> 活動目錄用戶和計算機.
3. 建立一個組織單元 SQL Server 如果物件不存在，則不建立物件。
4. 確認所有叢集節點的電腦物件都存在於 Active Directory 中。
5. 確保網域名稱系統（DNS）服務配置正確，並且所有伺服器名稱都能正確解析。

4.1.2 建立服務帳戶

建立專用的 Active Directory 服務帳戶 SQL Server 每個節點上的服務。

1. 未結案工單 活動目錄用戶和計算機 在網域控制器上。
2. 右鍵單擊相應的組織單元並選擇 New -> 用戶名单 .
3. 輸入服務帳戶名稱（例如，svc_SQLServer）並進行設定 使用者登入名稱.
4. 點擊 下一則 並輸入一個強密碼。
5. 選擇 用戶不能更改密碼 以及 密碼永不過期.
6. 點擊 下一則 進而 完 創建帳戶。
7. 重複以上步驟，直至取得所需的其他服務帳戶（SQL Server 代理、SSRS 等）。

4.1.3 配置管理員權限

服務帳戶和用於配置的帳戶 SQL Server 必須擁有對所有叢集節點的相應權限。

1. 登入每個叢集節點伺服器。
2. 未結案工單 計算機管理 來自 Start 選單或伺服器管理員。
3. 拓展 本地用戶和組 並選擇 商家類別.
4. 右鍵單擊 管理員 並選擇 物業.
5. 點擊 新增 然後輸入服務帳戶名稱。
6. 點擊 檢查姓名 驗證帳戶，然後按一下 OK.
7. 點擊 OK 關閉“管理員屬性”對話框。
8. 在所有叢集節點上重複上述步驟。

4.2 安裝和設定 WSFC

在啟用 Always On 可用性群組之前，必須先在所有節點上安裝並設定 Windows Server 故障轉移叢集。

4.2.1 安裝故障轉移群集功能

在將要加入可用性群組的每台伺服器上安裝故障轉移叢集功能。

1. 未結案工單 服務器管理器 在第一個叢集節點上。
2. 點擊 管理 -> 添加角色和功能.
3. 點擊 下一則 透過介紹螢幕。
4. 選擇 基於角色或基於功能的安裝 並點擊 下一則.
5. 選擇本機伺服器並點擊 下一則.
6. 跳過“角色”畫面並點擊 下一則.
7. 在「功能」畫面上，選擇 故障轉移群集.
8. 點擊 新增功能 當被要求新增管理工具時。
9. 點擊 下一則 進而 安裝.
10. 等待安裝完成並點擊 關閉.
11. 對叢集中所有伺服器重複上述步驟。

4.2.2 建立故障轉移群集

在所有節點上安裝故障轉移叢集功能後，從其中一個節點建立叢集。

1. 未結案工單 故障轉移群集管理器 服務器管理器 -> 工具.
2. 點擊 創建集群 在「操作」窗格中。
3. 點擊 下一則 在「開始之前」頁面上。
4. 點擊 瀏覽 新增所有將作為叢集節點的伺服器。
5. 點擊 下一則 新增完所有節點後。
6. 離開 運行所有測試（建議） 選取並點擊 下一則.
7. 審查驗證測試結果，並處理任何錯誤或警告。
8. 點擊 完 驗證成功完成後。
9. 請輸入群集名稱和 IP 位址。
10. 取消選中 將所有符合條件的儲存新增至集群 因為不需要共享儲存。
11. 點擊 下一則 並查看確認訊息。
12. 點擊 完 建立集群。

4.2.3 驗證叢集配置

驗證叢集配置，確保所有節點都能正常通信，且叢集運作正常。

1. In 故障轉移群集管理器右鍵單擊叢集名稱。
2. 選擇 驗證集群 從菜單。
3. 點擊 下一則 在「開始之前」頁面上。
4. 選擇 運行所有測試（建議） 並點擊 下一則.
5. 點擊 下一則 開始驗證測試。
6. 測試完成後，請查看驗證報告。
7. 解決報告中指出的所有故障或警告。
8. 點擊 完 關閉嚮導。

4.3 安裝 SQL Server 可用性組

安裝 SQL Server 在每個將參與可用性群組的節點上使用獨立安裝選項。

1. 跑過 SQL Server 在第一個節點上安裝介質。
2. 選擇 New SQL Server 獨立安裝.
3. 輸入產品金鑰或選擇評估版。
4. 接受許可條款並點擊 下一則.
5. 完成所有必要檢查並解決任何問題。
6. 在「功能選擇」頁面上，選擇 資料庫引擎服務.
7. 配置實例名稱（在所有節點上使用相同的實例名稱）。
8. 在伺服器設定頁面上，指定服務帳戶憑證。
9. 配置服務tartup 類型為 Automatic 自動錶.
10. 在資料庫引擎設定頁面上，選擇身份驗證模式。
11. 新增管理員帳戶。
12. 配置資料目錄，使其在所有節點上保持一致的路徑。
13. 完成安裝並驗證是否成功。
14. 使用相同的設定對叢集中的所有其他節點重複安裝。

4.4 啟用 Always On 可用性群組功能

安裝後 SQL Server 在所有節點上，為每個實例啟用 Always On 可用性群組功能。

4.4.1 透過以下方式啟用 SQL Server 配置管理器

使用 SQL Server 透過圖形介面使用設定管理器啟用 Always On 可用性群組。

1. 未結案工單 SQL Server 配置管理器 在第一個節點上。
2. 拓展 SQL Server 服務範圍 在左側窗格中。
3. 用鼠標右鍵單擊 SQL Server 實例並選擇 物業.
4. 在操作欄點擊 AlwaysOn 高可用性 標籤。
5. 勾選 啟用 AlwaysOn 可用性群組.
6. 請確認Windows故障轉移群集名稱是否正確。
7. 點擊 OK 保存更改。
8. 點擊 OK 警告稱該服務必須恢復tar特德。
9. 用鼠標右鍵單擊 SQL Server 服務和選擇 住宅tart.
10. 等待服務恢復tar成功。
11. 在所有叢集節點上重複上述步驟。

4.4.2 透過 PowerShell 啟用

PowerShell 提供了一種腳本方法來跨多個節點啟用 Always On 可用性群組。

1. 在第一個節點上以管理員身分開啟 PowerShell。
2. 導入 SQL Server PowerShell 模組：

   Import-Module SQLPS -DisableNameChecking

3. 啟用 Always On 可用性群組：

   Enable-SqlAlwaysOn -ServerInstance "ServerName\InstanceName" -Force

4. 該服務將自動恢復。tar使用 Force 參數時。
5. 請確認該功能已啟用：

   Get-ItemProperty "SQLSERVER:\SQL\ServerName\InstanceName" | Select-Object IsHadrEnabled

6. 對每個叢集節點重複上述步驟，替換為對應的伺服器和實例名稱。

4.4.3 驗證功能是否已啟用

在繼續設定之前，請確認所有實例上都已啟用 Always On 可用性群組。

1. 連接到每個 SQL Server 使用實例 SQL Server 管理工作室。
2. 開啟一個新的查詢視窗並執行：

   SELECT SERVERPROPERTY('IsHadrEnabled')

3. 確認結果為 1（已啟用）。
4. 檢查一下 SQL Server 實例出現在故障轉移群集管理器中的群集角色下。
5. 透過執行以下命令驗證可用性群組端點是否存在：

   SELECT * FROM sys.endpoints WHERE type_desc = 'DATABASE_MIRRORING'

6. 如果端點不存在，則會在建立可用性群組期間建立該端點。

4.5 為可用性群組準備資料庫

資料庫必須滿足特定要求才能新增至可用性群組。

4.5.1 資料庫復原模型要求

在將主副本新增至可用性群組之前，請將其資料庫復原模式變更為 FULL。

1. 使用以下方式連接到主副本 SQL Server 管理工作室。
2. 右鍵單擊資料庫並選擇 物業.
3. 點擊 選項 頁。
4. 更改 恢復模式 至 全.
5. 點擊 OK 以保存更改。
6. 或者，使用 Transact-SQL：

   ALTER DATABASE DatabaseName SET RECOVERY FULL;

4.5.2 執行完整資料庫備份

對資料庫進行完整備份，以建立可用性群組所需的備份鏈。

1. In SQL Server 在 Management Studio 中，右鍵點選資料庫。
2. 選擇 任務 -> 備份.
3. 確認 備份類型 被設置為 全.
4. 選擇備份目標位置或新增目標位置。
5. 點擊 OK 執行備份。
6. 或者，使用 Transact-SQL：

   BACKUP DATABASE DatabaseName TO DISK = 'C:\Backup\DatabaseName.bak';

4.5.3 進行交易日誌備份

進行交易日誌備份，以確保日誌鏈已建立，並最大限度地縮短初始化時間。

1. In SQL Server 在 Management Studio 中，右鍵點選資料庫。
2. 選擇 任務 -> 備份.
3. 更改 備份類型 至 交易日誌.
4. 選擇備份目標位置。
5. 點擊 OK 執行備份。
6. 或者，使用 Transact-SQL：

   BACKUP LOG DatabaseName TO DISK = 'C:\Backup\DatabaseName.trn';

4.6 建立可用性群組

根據您的偏好和自動化要求，可以使用幾種可用方法之一來建立可用性群組。

4.6.1 使用新建可用性群組精靈

新可用性群組精靈提供了一個用於建立可用性群組的圖形介面。

1. In SQL Server Management Studio，連線到將要執行的實例ost 主副本。
2. 拓展 AlwaysOn 高可用性 在物件資源管理器中。
3. 右鍵單擊 可用性組 並選擇 新建可用性群組精靈.
   
4. 點擊 下一則 在簡介頁。
5. 輸入可用性群組的名稱，然後按一下 下一則.
6. 在「選擇資料庫」頁面上，選擇要包含的資料庫。
7. 確認資料庫滿足所有先決條件，然後按一下 下一則.
8. 在「指定副本」頁面上，按一下 新增副本.
9. 連線到每個輔助副本實例。
10. 為每個實例配置副本屬性（可用性模式、故障轉移模式）。
11. 在操作欄點擊 端點 點選查看端點配置。
12. 在操作欄點擊 備份首選項 切換到「備份優先權」標籤並配置備份優先權。
13. 在操作欄點擊 傾聽者 按下選項卡，並可選擇建立監聽器。
14. 點擊 下一則 並選擇資料同步方法。
15. 審查驗證結果並解決任何問題。
16. 點擊 下一則 並審閱摘要。
17. 點擊 完 建立可用性群組。
18. 監控進度並驗證建立是否成功。

4.6.2 使用 Transact-SQL

使用 Transact-SQL 建立可用性群組，實現可腳本化、可重複的部署。

1. 在主副本上建立可用性群組：

   CREATE AVAILABILITY GROUP AG_Name
   FOR DATABASE DatabaseName
   REPLICA ON
     'PrimaryServer\Instance' WITH
       (ENDPOINT_URL = 'TCP://PrimaryServer:5022',
        AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
        FAILOVER_MODE = AUTOMATIC,
        SECONDARY_ROLE(ALLOW_CONNECTIONS = ALL)),
     'SecondaryServer\Instance' WITH
       (ENDPOINT_URL = 'TCP://SecondaryServer:5022',
        AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
        FAILOVER_MODE = AUTOMATIC,
        SECONDARY_ROLE(ALLOW_CONNECTIONS = ALL));

2. 將輔助副本加入可用性群組：

   ALTER AVAILABILITY GROUP AG_Name JOIN;

3. 加入輔助資料庫：

   ALTER DATABASE DatabaseName SET HADR AVAILABILITY GROUP = AG_Name;

4.6.3 使用 PowerShell

PowerShell 提供用於建立和管理可用性群組的腳本功能。

1. 建立可用性群組物件：

   $AG = New-SqlAvailabilityGroup -Name "AG_Name" -Path "SQLSERVER:\SQL\PrimaryServer\Instance"

2. 新增資料庫：

   Add-SqlAvailabilityDatabase -Path "SQLSERVER:\SQL\PrimaryServer\Instance\AvailabilityGroups\AG_Name" -Database "DatabaseName"

3. 使用 New-SqlAvailabilityReplica cmdlet 設定具有所需屬性的副本。
4. 使用 Join-SqlAvailabilityGroup cmdlet 連接輔助副本。

4.7 向可用性群組新增副本

配置副本特定屬性，以控制每個實例如何參與可用性群組。

4.7.1 配置副本屬性

為每個副本設定屬性，以定義其在可用性群組中的角色和功能。

1. In SQL Server 管理工作室，擴展 AlwaysOn 高可用性 -> 可用性組.
2. 展開可用性組，然後展開 可用性副本.
   
3. 右鍵單擊副本並選擇 物業.
4. 檢查並修改主角色和輔助角色的連線設定。
5. 如有需要，請配置會話逾時值。
6. 點擊 OK 保存更改。

4.7.2 設定可用性模式

配置可用性模式以控制副本之間的同步行為。

1. 右鍵單擊可用性群組並選擇 物業.
2. 在 一般說明 頁面，轉至 可用性副本 部分。
3. 對於每個副本，選擇 同步提交 or 非同步提交 從下拉列表。
4. 對本地高可用性副本使用同步提交。
5. 對地理位置分散的災難復原副本使用非同步提交。
6. 點擊 OK 以保存配置。

4.7.3 設定故障轉移模式

配置故障轉移模式，以控制每個副本的故障轉移方式。

1. 右鍵單擊可用性群組並選擇 物業.
2. 在 一般說明 頁面，轉至 可用性副本 部分。
3. 對於同步提交副本，請選擇 Automatic 自動錶 or 手動操作 故障轉移模式。
4. 自動故障轉移需要同步提交模式，並支援無人值守故障轉移。
5. 對於非同步提交副本，僅支援手動故障轉移。
6. 最多可配置三個副本以實現自動故障轉移（一個主副本和兩個輔助副本）。
7. 點擊 OK 應用設置。

4.7.4 配置備份首選項

設定備份首選項以控制備份操作的執行位置。

1. 右鍵單擊可用性群組並選擇 物業.
2. 選擇 備份首選項 在左側窗格中。
3. 選擇以下備份首選項之一：
   • 更喜歡中學：如果備用備份可用，則備份到備用備份磁碟；否則備份到主備份磁碟。
   • 限副修僅在輔助副本上進行備份
   • 主僅在主副本上進行備份
   • 任何複製品：在任何可用副本上進行備份
4. 為每個副本設定備份優先值（0-100）。
5. 優先權越高表示首選備份方案。 tar得到。
6. 點擊 OK 儲存設定。

4.8 設定可用性群組偵聽器

建立一個監聽器，提供一個單一的連接點，該連接點會自動重新導向到目前主副本。

4.8.1 建立監聽器

為可用性群組新增用戶端連線管理監聽器。

1. In SQL Server Management Studio，展開可用性組。
2. 右鍵單擊 可用性群組監聽器 並選擇 新增監聽器.
   
3. 輸入監聽器的 DNS 名稱（例如，AG_Listener）。
4. 輸入連接埠號碼（預設值為 1433）。
5. 選擇 靜態IP 用於網路模式。
6. 點擊 新增 為每個子網路新增一個IP位址。
7. 輸入IP位址並選擇子網路。
8. 點擊 OK 建立監聽器。
9. 確認監聽器出現在物件資源管理器中且處於連線狀態。

4.8.2 配置 DNS 和 IP 設定

請驗證監聽器的 DNS 註冊和網路設定。

1. 在網域控制器上開啟DNS管理器。
2. 確認監聽器名稱已註冊到所有 IP 位址。
3. 從客戶端電腦測試 DNS 解析：

   nslookup ListenerName

4. 確認所有已設定的IP位址均已回傳。
5. 在故障轉移群集管理器中，展開 角色 並選擇可用性群組。
6. 請確認IP位址資源是否在線。
7. 檢查網路名稱資源是否線上。
   

4.8.3 測試監聽器連接性

驗證客戶端應用程式是否可以透過監聽器連線。

1. 從客戶端計算機開啟 SQL Server 管理工作室。
2. 使用監聽器名稱而不是伺服器名稱進行連線。
3. 執行查詢以驗證與目前主副本的連線：

   SELECT @@SERVERNAME;

4. 透過在連接字串中新增 ApplicationIntent=ReadOnly 來測試讀取意圖路由。
5. 驗證連線是否會重新導向到可讀的輔助副本。
6. 手動將可用性群組切換到故障轉移狀態並驗證重新連接，以此測試故障轉移功能。

4.9 資料同步方法

選擇一種資料同步方法來初始化資料庫副本的輔助副本。

4.9.1 自動播種

自動種子數據透過網路傳輸資料庫數據，無需手動備份和恢復。

1. 在建立可用性群組期間，選擇 自動播種 作為同步方法。
   
2. 確保副本之間的網路連線和足夠的頻寬。
3. 主副本會自動將資料庫資料串流傳輸到輔助副本。
4. 使用可用性群組儀表板或 DMV 監控種子部署進度。
5. 自動播種需要 SQL Server 2016或更高版本。
6. 對於大型資料庫，應考慮網路影響，並在低使用時段進行排程。

4.9.2 手動播種（備份和還原）

手動備份是指在主伺服器上進行備份，然後將備份還原到輔助副本上。

1. 在主副本上，進行完整備份：

   BACKUP DATABASE DatabaseName TO DISK = '\\SharePath\DatabaseName.bak';

2. 備份交易日誌：

   BACKUP LOG DatabaseName TO DISK = '\\SharePath\DatabaseName.trn';

3. 在每個輔助副本上，還原完整備份：

   RESTORE DATABASE DatabaseName FROM DISK = '\\SharePath\DatabaseName.bak' WITH NORECOVERY;

4. 復原日誌備份：

   RESTORE LOG DatabaseName FROM DISK = '\\SharePath\DatabaseName.trn' WITH NORECOVERY;

5. 將資料庫加入可用性群組：

   ALTER DATABASE DatabaseName SET HADR AVAILABILITY GROUP = AG_Name;

6. 驗證同步開始，資料庫達到 SYNCHRONIZED 狀態。

4.9.3 資料庫快照文件

使用資料庫快照檔案從現有資料庫檔案初始化輔助副本。

1. 從主副本上分離或備份資料庫。
2. 使用相同的檔案路徑將資料庫檔案複製到每個輔助副本。
3. 在輔助副本上，附加資料庫或復原資料庫而不進行復原。
4. 確保資料庫處於復原狀態。
5. 將資料庫加入可用性群組。
6. 這種方法適用於網路傳輸不切實際的大型資料庫。

5。 常問問題

5.1 一般問題

Q：Always On FCI 和 Always On AG 有什麼不同？

答：Always On 故障轉移叢集執行個體使用共用儲存提供執行個體級高可用性，而 Always On 可用性群組則不使用共用儲存體提供資料庫級高可用性。可用性群組提供可讀輔助資料庫和更靈活的地理分佈。

Q：我可以將 Always On 可用性群組與以下情況一起使用： SQL Server 標準版？

答：是的， SQL Server 2016 標準版及更高版本支援基本可用性群組，但存在一些限制，包括每個可用性群組只能有一個資料庫、最多兩個副本，且不支援可讀輔助資料庫。

Q：Always On可用性群組需要共用儲存嗎？

答：不，可用性組不需要共用儲存。每個副本都在本機儲存上維護獨立的資料庫副本，並透過交易日誌傳送進行同步。

Q：可用性群組中最多可以有多少個副本？

A: SQL Server 企業版最多支援九個副本（一個主副本和八個輔助副本）。分散式可用性組最多可支援兩個可用性組共 18 個副本。

5.2 配置問題

Q：如何選擇同步提交模式還是非同步提交模式？

答：對於同一資料中心或低延遲網路中零資料遺失要求，請使用同步提交。對於遠端災難復原副本，如果同步提交會影響效能，請使用非同步提交。

Q：我可以在同一個可用性群組中混合使用同步副本和非同步副本嗎？

答：是的，可用性群組支援同步副本和非同步副本的混合配置。這使得同步副本能夠實現本地高可用性，非同步副本能夠實現遠端災難復原。

Q：故障轉移期間我的連線會發生什麼事？

答：發生故障轉移時，現有連線將被中斷。具有連接重試邏輯的應用程式會自動透過監聽器重新連接到新的主節點。故障轉移過程通常會在幾秒鐘到幾分鐘內完成。

Q：我是否需要跨副本同步登入資訊和作業？

答：在 SQL Server 2019 年及更早版本，是的－登入名稱、SQL Agent 作業和連結伺服器必須手動同步。 SQL Server 2022 年引入了包含可用性群組，這些物件會自動包含在內。

5.3 管理問題

Q：我可以在輔助副本上執行備份嗎？

答：是的，輔助副本支援完整備份、差異備份和交易日誌備份。配置備份首選項，將備份任務從主副本卸載，從而降低其資源佔用。

Q：如何打補丁？ SQL Server 盡量減少停機時間？

答：採用滾動升級的方式，先修補輔助副本，然後手動故障轉移到已修補的輔助副本，最後修補原主副本。這樣可以將停機時間控制在故障轉移期間。

Q：我可以將資料庫新增到現有的可用性群組嗎？

答：是的，資料庫可以加入到正在運行的可用性群組。資料庫必須處於完整復原模式並擁有完整備份，輔助副本必須使用自動初始化或手動備份和復原進行初始化。

Q：什麼是自動播種？我應該使用它嗎？

答：自動初始化是指透過網路傳輸資料庫資料來初始化輔助副本，無需手動備份。適用於小型資料庫或網路頻寬充足的情況。對於非常大的資料庫，手動初始化可能更快。

Q：在可用性群組中，我應該在哪裡執行 DBCC CHECKDB？

答：您應該在輔助副本上執行 DBCC CHECKDB，以減輕主副本的負載。資料庫一致性檢查可以在不影響主副本效能的情況下對輔助資料庫執行。

有關 DBCC CHECKDB 的更多詳細信息，請參閱我們的 綜合指南.

5.4 故障排除問題

Q：為什麼我的資料庫處於「未同步」狀態？

答：常見原因包括網路連線問題、資料傳輸暫停、輔助副本磁碟空間不足或終端問題。請檢查同步運轉狀況描述和 SQL Server 錯誤日誌包含具體詳細資訊。如果輔助資料庫已進入錯誤日誌，則需要查看輔助資料庫的錯誤日誌。 恢復狀態 或演出 待恢復請參閱相關連結指南。 tar已修復。

Q：當主伺服器不可用時，如何強制進行故障轉移？

答：連線到輔助副本並執行 ALTER AVAILABILITY GROUP AG_Name FORCE_FAILOVER_ALLOW_DATA_LOSS 指令。此操作會確認潛在的資料遺失，並將輔助副本立即提升為主副本。

Q：為什麼客戶端無法連接到我的監聽器？

A：在故障轉移群集管理器中驗證監聽器是否在線，DNS 註冊是否成功，所有監聽器 IP 是否可從客戶端訪問，以及防火牆規則是否允許流量流向監聽器連接埠。

Q：大型重做隊列意味著什麼？

答：過大的重做佇列表示輔助副本無法及時套用到達的日誌記錄。這可能表示磁碟 I/O 瓶頸、CPU 限製或輔助副本上的唯讀查詢阻塞。

Q：如果災難影響到所有副本，而我的備份也損壞了，我該怎麼辦？

答：這種最壞的情況，雖然極為 rar例如，勒索軟體攻擊、大規模儲存故障或連鎖災難都可能導致資料遺失。您的首要防禦措施是預防：維護地理位置分散的副本，將備份儲存在不同的位置，以及
定期測試您的災難復原流程。如果所有標準復原選項都失敗，則需要專門的災難復原方案。 SQL 資料復原工具 可以嘗試從損壞的 MDF 文件中提取數據，作為緊急的最後手段。

5.5 許可和 Cost 解答疑問（Questions）：

Q：Always On 可用性群組的許可方式是什麼？

A: SQL Server 許可取決於版本和部署模型。企業版可用性群組要求所有副本都必須擁有企業版授權。被動輔助副本在特定條件下可能符合免費許可條件。

問：可以用嗎 SQL Server 可用性群組的開發者版本？

答：是的，開發者版包含企業版的所有功能，包括完整的可用性群組支援。但是，它僅授權用於開發和測試，不得用於生產環境。

Q：可讀二級文件是否需要額外許可證？

答：許可取決於具體應用場景。用於災難復原的被動式輔助伺服器通常不需要許可證。服務於唯讀工作負載的主動式輔助伺服器通常需要許可，但具體條款可能有所不同。

Q：有沒有免費的方法可以實現高可用性？ SQL Server?

A: SQL Server Express Edition 不支援可用性群組。 SQL Server 標準版支援基本可用性組tar與… SQL Server 2016 年，標準版授權提供基本的高可用性 costs.

Q：什麼是分散式可用性群組？

答：分散式可用性群組是一種特殊的可用性群組，它跨越兩個獨立的可用性群組，能夠實現傳統可用性群組無法勝任的場景。它於[此處應填寫引入日期]被引入。 SQL Server 2016 年，分散式可用性小組解決了擴展性和地理分佈要求。

6. 結論

6.1 總結

SQL Server Always On 可用性群組是微軟為關鍵任務資料庫提供的頂級高可用性和災難復原解決方案。它們提供資料庫級故障轉移，無需共享儲存；提供可讀的輔助副本以卸載工作負載；並具有靈活的地理分佈，可實現全面的資料保護。對於仍在運行諸如以下解決方案的組織： 原木運輸 or 複製可用性組提供了更強大、操作更簡單的升級途徑。

6.2 何時使用 Always On 可用性群組

當需要資料庫級高可用性和自動故障轉移功能時，請選擇可用性群組。對於需要為關鍵資料庫提供零資料遺失保護的組織而言，具有自動故障轉移功能的同步提交副本將大有裨益。需要讀取擴充功能的應用程式可以利用可讀輔助副本來指派查詢工作負載。

6.3 獲取 Star感謝您的實施

首先評估業務需求，包括復原時間目標 (RTO)、復原點目標 (RPO) 和預算限制，以此作為可用性群組規劃的起點。記錄目前資料庫基礎架構、應用程式依賴關係以及高可用性方面的不足。設計一個既能滿足需求又能控制在資源限制範圍內的可用性群組架構。

參考

• 微軟官方文件： 什麼是 Always On 可用性群組？
• 微軟官方文件： 獲得 Started 與 Always On 可用性群組
• 微軟官方文件： 分散式可用性組

---

關於作者

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

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

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

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