商務持續性與資料庫復原 - SQL Server

適用於 SQL Server 2016 (13.x) 和更新版本

本文提供適用於 Windows 和 Linux 上 SQL Server 高可用性和災害復原的商務持續性解決方案概觀。

所有部署 SQL Server 的人都必須確保所有關鍵任務的 SQL Server 實例及其資料庫在企業和終端用戶需要時都能隨時可用，無論是在正常營業時間還是全天候開放。 目標是維持企業運轉不中斷或將影響降至最低。 此概念也就是所謂的「商務持續性」。

SQL Server 2017（14.x）及後續版本引入了功能與增強功能以提升可用性。 最大的新增功能是支援 Linux 發行版的 SQL Server。 如需 SQL Server 新增功能的完整清單，請參閱下列文章：

版本	操作系統
SQL Server 2025（17.x）有什麼新內容	Windows | Linux
SQL Server 2022（16.x）有什麼新內容	Windows | Linux
SQL Server 2019（15.x）有什麼新內容	Windows | Linux
SQL Server 2017（14.x）新增內容	Windows | Linux

本文聚焦於 SQL Server 2017（14.x）及以後版本的可用性情境，以及新增與增強的可用性功能。 這些情境包括可跨越 Windows Server 與 Linux SQL Server 部署的混合型，以及可增加資料庫可讀副本數量的方案。

雖然本文未涵蓋 SQL Server 以外的可用性選項（如虛擬化），但此處討論的內容適用於訪客虛擬機內的 SQL Server 安裝，無論是在公共雲或由本地虛擬機管理程式伺服器託管。

使用 可用性功能的 SQL Server 情境

你可以使用 Always On 可用性群組、故障轉移叢集實例，和日誌運送來達成不同的目的，而不僅僅是為了提高可用性。 你可以主要有四種方式使用可用性功能：

• 高可用性
• 災害復原
• 移轉與升級
• 向外延展一或多個資料庫的可讀取複本

以下章節說明每種情境的相關特徵。 其中一項未涵蓋的功能是 SQL Server 複寫。 雖然 SQL Server 複製並未被正式指定為 Always On 的可用性功能，但在特定情境下，它常被用來使資料變得冗餘。 Linux 上的 SQL Server 不支援合併式複寫。 如需詳細資訊，請參閱 Linux 上的 SQL Server 複寫。

重要

SQL Server 可用性功能並不能取代必須有穩健且經過充分測試的備份與還原策略。 備份與還原策略是任何可用性解決方案最基本的基石。

高可用性

確保在資料中心或雲端的單一區域發生問題時，SQL Server 實例或資料庫仍然可用是非常重要的。 本節說明 SQL Server 可用性功能如何提供協助。 文中所述的所有功能皆可在 Windows Server 與 Linux 上使用。

可用性群組

可用性群組（AG）透過將資料庫的每個交易傳送到另一個實例或 副本，該副本包含該資料庫的特殊狀態副本，來提供資料庫層級的保護。 你可以在標準版或企業版部署 AG。 參與 AG 的執行個體可以是獨立執行個體，也可以是容錯移轉叢集執行個體 (也就是 FCI，下一節會予以說明)。 由於交易在發生時即會傳送至複本，建議在需要較低的復原點與復原時間目標時使用 AG。 複本之間的資料移動可為同步或非同步，而 Enterprise Edition 最多允許三個同步複本 (包括主要複本)。 AG 具備一個在主要複本上的資料庫完整讀寫複本，而所有次要複本都無法直接從終端使用者或應用程式接收交易。

注意

Always On 是 SQL Server 可用性功能的概括性術語，涵蓋了 AG 與 FCI。 Always On 不是 AG 功能的名稱。

在 SQL Server 2022 (16.x) 以前，AG 僅提供資料庫層級，而非執行個體層級的保護。 任何未在交易日誌中擷取或未在資料庫中設定的內容，必須為每個次要副本手動同步。 有些必須以手動方式同步處理的物件範例，是在執行個體層級、連結的伺服器和 SQL Server Agent 作業的登入。

在 SQL Server 2022（16.x）及更新版本中，除了實例層級外，還能管理中繼資料物件，包括使用者、登入、權限及 SQL Server 代理工作。 如需詳細資訊，請參閱什麼是自主可用性群組？

AG 還有稱為「接聽程式」的另一個元件，其讓應用程式與終端使用者無需知道裝載主要複本的是哪個 SQL Server 執行個體，即可進行連線。 每個總檢察長都有自己的聽眾。 雖然 Windows Server 與 Linux 的監聽器實作略有不同，但兩者提供相同的功能和可用性。 下圖展示了一個基於 Windows Server 的 AG，該 AG 正在使用 Windows Server 故障轉移叢集（WSFC）。 OS 層的基礎叢集需要才能提供可用性，無論是在 Linux 或 Windows Server 上。 此範例顯示了兩部伺服器 (或稱「節點」) 的簡易設定，而 WSFC 則作為基礎叢集。

Standard Edition 與 Enterprise Edition 的複本數量上限各有不同。 Standard Edition 中的 AG 又稱為基本可用性群組，在 AG 中僅支援單一資料庫的兩個複本 (一個主要、一個次要)。 Enterprise Edition 不只允許在單一 AG 中設定多個資料庫，而且總計最多可以有 9 個複本 (一個主要、八個次要)。 Enterprise Edition 也提供其他選擇性的優點，例如可讀取的次要複本、製作次要複本備份的能力，及其他更多。

注意

資料庫鏡像功能在 SQL Server 2012（11.x）中被棄用，Linux 版本的 SQL Server 不支援，也未被新增。 仍在使用資料庫鏡像的客戶應規劃移轉至取代資料庫鏡像的 AG。

AG 可針對可用性提供自動或手動容錯移轉。 如已設定同步資料移動，且主要與次要複本的資料庫為同步處理狀態，就會發生自動容錯移轉。 只要使用監聽器且應用程式使用支援的 .NET Framework 版本（3.5 含 Service Pack 1，或 4.6.2 及更新版本），若使用監聽器，故障轉移對終端使用者的影響應該極小甚至不受影響。 容錯移轉至次要複本使其成為新主要複本的作業可以設定成自動或手動進行，而且通常以秒計。

下列清單醒目提示 Windows Server 與 Linux 上 AG 的一些差異：

由於底層叢集在 Linux 和 Windows Server 上的運作方式，所有 AG 故障轉移（手動或自動）都是透過叢集在 Linux 上完成的。 在 Windows Server 型 AG 部署上，手動容錯移轉必須透過 SQL Server 來完成。 自動容錯移轉是由 Windows Server 和 Linux 上的基礎叢集控制。

• 在 Linux 上使用 SQL Server，你應該配置至少三個副本的 AG，這是因為底層叢集的運作方式。

• 在 Linux 上，每個接聽程式使用的通用名稱是在 DNS 中定義的，而不是像在 Windows Server 上那樣在叢集中定義。

SQL Server 2017（14.x）為 AG 引入了以下功能與增強功能：

• 叢集類型
• REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT
• Windows Server 組態的增強式 Microsoft 分散式交易協調器 (DTC) 支援
• 適用於唯讀資料庫的其他擴增案例 (此文章稍後將會敘述)

可用性群組叢集類型

Windows Server 叢集的內建可用性形式是透過名為容錯移轉叢集功能啟用。 其可讓您建置要搭配 AG 或 FCI 使用的 WSFC。 SQL Server 附帶叢集感知的資源 DLL，提供 AG 與 FCI 的整合。

Linux 上的 SQL Server 支援多種群集技術 (部分機器翻譯)。 Microsoft 支援 SQL Server 元件，而我們的夥伴則支援相關的群集技術。 例如，除了 Pacemaker 之外，Linux 上的 SQL Server 還支援 HPE Serviceguard (部分機器翻譯) 與 DH2i DxEnterprise (部分機器翻譯) 作為叢集解決方案。

Windows 型容錯移轉叢集與 Linux 叢集解決方案之間同大於異。 它們都提供一種方式，採用個別伺服器並將它們結合在一個組態以提供可用性，而且有資源、條件約束 (即使實作方式不同)、容錯移轉等等項目的概念。

例如，為了對自動容錯移轉等 AG 與 FCI 設定支援 Pacemaker，Microsoft 為 Pacemaker 提供了 mssql-server-ha 套件，此套件與 WSFC 中的資源 DLL 相似，但並不完全相同。 WSFC 與 Pacemaker 的其中一個差異，是 Pacemaker 沒有網路名稱資源，這是可在 WSFC 上將接聽程式名稱 (或 FCI 名稱) 抽象化的元件。 在 Linux 上使用 DNS 來解析名稱。

由於叢集堆疊的差異，SQL Server 2017（14.x）及後續版本的 AG 需要處理部分由 WSFC 原生處理的元資料。 例如，可用性群組有三種 叢集類型 ，分別存放 sys.availability_groups 在 cluster_type 和 cluster_type_desc 欄位中：

• WSFC
• 外部
• 沒有

所有需要高可用性的 AG 都必須使用基礎叢集，若為 SQL Server 2017 (14.x) 與更新版本，則代表須使用 WSFC 或 Linux 群集代理程式。 對於使用 Windows Server 基礎 WSFC 的 AG，預設叢集類型是 WSFC，且不需要設定。 對於基於 Linux 的 AG，建立 AG 時必須將叢集類型設為 External 。 外部叢集解決方案整合在 Linux 中會在 AG 建立後進行設定，而在 WSFC 中則會在建立時完成。

「無」叢集類型可搭配 Windows Server 與 Linux AG 使用。 將叢集類型設定為 [無] 表示 AG 不需要有基礎叢集。 這代表 SQL Server 2017 (14.x) 是第一個對不具叢集的 AG 提供支援的 SQL Server 版本，但代價是此設定不支援作為高可用性解決方案。

重要

在 SQL Server 2017 （14.x） 和更新版本中，您無法在建立 AG 之後變更叢集類型。 這個限制意味著 AG 不能從 None 切換到 External 或 WSFC，反之亦然。

如果你只想新增額外的唯讀資料庫副本，或是想使用 AG 提供的遷移與升級功能，但不想處理底層叢集甚至複寫的複雜性，可以考慮設定叢集類型為 None 的 AG。 如需詳細資訊，請參閱 移轉和升級 和 讀取擴展一節。

下列螢幕快照顯示 SQL Server Management Studio （SSMS） 中不同種類叢集類型的支援。 您必須執行版本 17.1 或更新版本。 以下截圖來自版本 17.2：

必需同步的副本才能提交

SQL Server 2016 (13.x) 對 Enterprise Edition 的同步複本數目支援，從兩個增加到三個。 然而，如果一個次要副本同步，但另一個副本有問題，就無法控制行為，告訴主副本要麼等待異常副本，要麼讓它繼續前進。 在這種情況下，即使次要副本未同步，主副本仍可能接收寫入流量，導致次要副本的資料遺失。

在 SQL Server 2017 （14.x） 和更新版本中，您可以控制當有同步複本時 REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT所發生的行為。 此選項的運作方式如下：

• 有三個可能的值： 0、、 1和 2。
• 該值為必須同步的次要副本數量，這會影響資料遺失、AG 可用性及故障轉移。
• 對於 WSFC 和叢集類型 None，預設值是 0，你可以手動設定為 1 或 2。
• 對於外部類型的叢集，叢集機制預設會設定這個值，你可以手動進行覆寫。 對於三個同步副本，預設值為 1。

在 Linux 上，可以在叢集的 AG 資源上配置 REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT 的值。 在 Windows 上，你可以透過 Transact-SQL 設定。

高於 的 0 數值能保證更高的資料保護，因為如果無法取得所需的次要副本數量，主副本在該條件解決前無法使用。 REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT 同時也會影響故障轉移的行為，因為如果次要副本的數量不足或不是正確的狀態，自動故障轉移無法發生。 在 Linux 上，值 0 不允許自動故障轉移，因此在使用同步且具有自動故障轉移的情況下，必須將值設得高於 0 才能實現自動故障轉移。 在 Windows Server 上設定為 0 是 SQL Server 2016 (13.x) 與更舊版本的行為。

增強式 Microsoft 分散式交易協調器支援

在 SQL Server 2016（13.x）之前，對於需要分散式交易（底層使用 DTC）的應用程式，唯一能在 SQL Server 中取得可用性的方法，就是部署 FCI。 下列兩種方式可以完成分散式交易：

• 一個跨越同一 SQL Server 實例中多個資料庫的交易。
• 跨越多個 SQL Server 實例，或可能涉及非 SQL Server 資料來源的交易。

SQL Server 2016 (13.x) 透過 AG 引進了 DTC 部分支援，涵蓋了第二個案例。 SQL Server 2017 (14.x) 可透過 DTC 支援這兩個案例，完整涵蓋所有情境。

在 SQL Server 2017（14.x）及之後的版本中，您可以在建立 AG 之後，新增 DTC 支援。 在 SQL Server 2016（13.x）中，你只能在建立 AG 時啟用 DTC 支援。

容錯移轉叢集執行個體

故障轉移叢集實例（FCI）提供整個 SQL Server 安裝的可用性，稱為 實例。 使用 FCI，如果底層伺服器遇到問題，實例內的所有資料都會被移到另一台伺服器，包括資料庫、SQL Server 代理工作、連結伺服器等。 所有 FCI 都需要某種共享儲存空間，即使是網路定義的。 一個節點可以同時運行並擁有 FCI 的資源。 在下圖中，叢集的第一節點擁有 FCI。 它也擁有與之相關的共享儲存資源，而實體線即代表儲存空間。

故障轉移後，所有權會變更，如下圖所示：

FCI 沒有資料遺失，但底層的共用儲存是單一故障點，因為只有一份資料副本。 為了擁有資料庫的冗餘副本，可以將 FCI 與其他可用性方式結合，例如 AG 或日誌運送。 另一種方法必須使用與 FCI 物理分離的儲存空間。 當 FCI 切換到另一個節點時，會停止在一個節點，並從另一個節點開始。 這個過程類似於將伺服器關機再開機。

FCI 會經歷正常的復原程序。 它會前推需要向前推進的交易，並回滾任何未完成的交易。 因此，資料庫從一個資料點到故障或手動故障轉移的時間點都是一致的，因此不會有資料遺失。 資料庫僅在恢復完成後才能使用。 復原時間取決於多種因素，通常比因 AG 故障而長。 取捨是，當您容錯移轉 AG 時，可能需要額外的工作才能讓資料庫可用，例如啟用 SQL Server 代理程式作業。

注意

加速資料庫復原（ADR）可以縮短復原時間。 欲了解更多資訊，請參閱 加速資料庫復原。

如同 AG，FCI 會將其裝載所在的基礎叢集節點抽象化。 FCI 一律保留相同的名稱。 應用程式和終端使用者永遠不會連接到節點。 取而代之的是，他們使用FCI所擁有的獨特名稱。 FCI 可以參與 AG，作為其中一個裝載主要或次要複本的執行個體。

下列清單醒目提示 Windows Server 與 Linux 上 FCI 的一些差異：

• 在 Windows Server 上，FCI 是安裝程序的一部分。 安裝 SQL Server 後，你要在 Linux 上設定 FCI。
• Linux 每台主機只支援安裝單一 SQL Server，因此所有 FCI 都是預設實例。 Windows Server 最多每個 WSFC 支援 25 個 FCI。
• FCI 在 Linux 中使用的通用名稱是在 DNS 中定義，應該與為 FCI 建立的資源同名。

記錄傳送

如果復原點與復原時間目標更靈活，或資料庫並非高度關鍵任務，日誌傳遞是 SQL Server 另一項經過驗證的可用性功能。 根據 SQL Server 原生備份，記錄傳送程序會自動產生交易記錄備份，將其複製到一或多個稱為暖待命的執行個體，並自動將交易記錄備份套用至該待命。 記錄傳送使用 SQL Server Agent 作業，自動化備份、複製和套用交易記錄備份的程序。

使用日誌運送的最大優點是能考慮人為錯誤，因為可以延遲交易日誌的應用。 例如，如果有人發出UPDATE而沒有包含WHERE條款，則待命系統可能未實施這一變更，因此你可以在修復主系統時切換到待命系統。 雖然日誌傳送容易設定，但從主伺服器切換到備援伺服器（稱為 角色變更）始終是手動操作。 你透過 Transact-SQL 發起角色變更，並且像 AG 一樣，必須手動同步所有未被交易日誌捕捉的物件。 你需要為每個資料庫設定日誌運送，而單一 AG 可以包含多個資料庫。

記錄傳送與 AG 或 FCI 不同，並不會將角色變更抽象化，因此應用程式必須能夠處理。 無法使用 DNS 別名 (CNAME) 這類技術，但優劣各半，例如切換之後 DNS 重新整理所耗費的時間。

災害復原

當主要可用性位置發生重大事件，例如水災或地震時，企業必須準備讓系統在其他地方上線。 本節將介紹 SQL Server 可用性功能如何協助業務持續性。

可用性群組

AG的優點之一是你可以用單一功能配置高可用性與災難復原。 在無須確保共用儲存體也高度可用的情況下，更容易就能在一個資料中心內擁有用於高可用性的複本，並在其他資料中心擁有用於災害復原的遠端複本，且每個複本都有各自的儲存體。 擁有額外的資料庫複本是確保備援需做出的取捨。 下圖顯示跨越多個資料中心的 AG 範例。 一個主要複本負責保存所有同步處理的次要複本。

除了叢集類型為 None 的 AG 外，AG 要求所有副本都屬於同一底層叢集，無論是 WSFC 還是外部叢集解決方案。 在前述圖中，WSFC 被拉伸用於兩個不同的資料中心，無論使用哪個平台（Windows Server 或 Linux）都會增加複雜度。 跨距離延展叢集會增加複雜性。

SQL Server 2016 (13.x) 引進的分散式可用性群組，能讓一個 AG 跨越不同叢集的多個 AG 進行設定。 分散式 AG 可分離所有節點參與相同叢集的需求，讓災害復原的設定更容易。 如需分散式 AG 的詳細資訊，請參閱分散式可用性群組 (部分機器翻譯)。

容錯移轉叢集執行個體

你可以使用 FCI 進行災難復原。 和一般 AG 一樣，你必須將底層的叢集機制擴展到所有位置，這增加了複雜度。 對於 FCI，你還需要考慮共享儲存。 主站與備站台需要存取相同的磁碟。 為確保 FCI 使用的儲存裝置同時存在於兩個站點，請使用外部方法，例如儲存廠商在硬體層提供的功能。 或者，你可以在 Windows Server 中使用 Storage Replica。

記錄傳送

日誌運送是為 SQL Server 資料庫提供災難復原的最古老方法之一。 日誌傳送通常與 AG 和 FCI 搭配使用，以提供符合成本效益且更簡單的災難復原，而其他選項可能會因環境、管理技能或預算而具有挑戰性。 類似於日誌傳送的高可用性方案，許多環境會延遲載入交易日誌以考慮人為錯誤。

移轉與升級

當組織部署新實例或升級舊實例時，無法容忍長時間的停機。 本節討論如何使用 SQL Server 的可用性功能，將計劃的架構變更、伺服器切換、平臺變更 （例如 Windows Server 轉為 Linux 或反之亦然） 或修補期間的停機時間降到最低。

注意

你也可以使用其他方法，例如備份和還原，來進行遷移和升級。 本文不討論這些方法。

可用性群組

你可以將包含一個或多個可用性群組（AG）的現有實例升級到更高版本的 SQL Server。 雖然此升級需要一定的停機時間，但只要有適當的規劃，可以將停機時間降到最低。

如果你想遷移到新伺服器而不更改設定（包括作業系統或 SQL Server 版本），請將這些伺服器作為現有底層叢集的節點加入，然後再加入 AG。 當複本或多個副本進入正確狀態後，手動切換到新伺服器。 接著，將舊伺服器從 AG 移除並停用。

分散式 AG 也是移轉至新組態或升級 SQL Server 的另一種方法。 由於分散式 AG 支援不同架構下的底層 AG，你可以從在 Windows Server 2019 上運行的 SQL Server 2019（15.x）切換到在 Windows Server 2025 上運行的 SQL Server 2025（17.x）。

最後，擁有叢集類型 None 的 AG 用於遷移或升級。 在典型的 AG 配置中，你無法混搭叢集類型，所以所有副本都必須是 None 類型。 分散式 AG 可用來跨越設有不同叢集類型的 AG。 這個方法在各種不同的作業系統平台上也受到支援。

所有用於遷移與升級的 AG 變體，都允許資料同步——最耗時的工作部分——分散進行。 當要啟動切換到新配置時，切換只是短暫的中斷，而不是一段長時間的停機，所有工作（包括資料同步）都必須完成。

AG 可以在補丁過程中手動將主副本切換到次要副本，從而在底層作業系統補丁時提供最小的停機時間。 從作業系統角度來看，這在 Windows Server 上較為常見，因為維護底層作業系統可能需要重新啟動。 修補 Linux 有時需要重啟，但這種情況較少見。

另一種減少停機時間的方法是根據 AG 架構的複雜度，修 補參與可用性群組的 SQL Server 實例。 你先修補一個次要複製品。 當適當數量的副本已打上補丁後，手動故障轉移主複本到另一個節點進行升級。 在那時升級任何剩餘的次要副本。

容錯移轉叢集執行個體

FCI 本身無法協助進行傳統的系統遷移或升級。 你必須在 FCI 裡設定 AG 或記錄運送，並記錄其他所有物件。 不過，當需要修補底層 Windows Server 時，FCI 仍是很受歡迎的選項。 當你啟動手動故障轉移時，短暫的斷線會取代 Windows Server 修補期間實例一直無法使用的情況。

你可以在原地將 FCI 升級到較新的 SQL Server 版本。 欲了解更多資訊，請參閱 升級故障轉移叢集實例。

記錄傳送

記錄傳送仍然是移轉和升級資料庫的熱門選項。 與 AG 相似，但這次是將交易記錄當作同步處理方法使用，在切換伺服器前讓資料傳播可以妥善開始。 在切換的同時，一旦所有流量都停在來源，就需要採用、複製最後一個交易記錄，並將它套用至新的組態。 此時，資料庫就可以上線了。

記錄傳送通常對較慢的網路更寬容，雖然交換可能比使用 AG 或分散式 AG 的交換稍長，但通常以分鐘為單位，而不是小時、天或週。

與 AG 類似，日誌運送也能提供在維護期間切換到另一台伺服器的方式。

其他 SQL Server 部署方法和可用性

Linux 的 SQL Server 另有兩種部署方法：容器和使用 Azure (或其他公用雲端提供者)。 無論 SQL Server 如何部署，可用性的普遍需求都存在。 這兩種方法在提升 SQL Server 可用性時有一些特別的考量。

SQL Server 容器與 HA/DR 選項

SQL Server 容器部署 是一種簡化 SQL Server 配置、擴展及生命週期管理跨環境的方式。 容器是完整且可執行的 SQL Server 映像檔。

根據你的容器平台，例如使用像 Kubernetes 這樣的容器編排器時，如果容器遺失，可以重新部署並附加到先前使用的共享儲存空間。 雖然這確實提供一些復原能力，但資料庫復原會有一些停機時間，而且不會像使用可用性群組或 FCI 那樣真正高可用性。

若您希望為部署在 Kubernetes 或非 Kubernetes 平台的 SQL Server 容器設定高可用性，除了可以在高可用性模式中設定 AG 的群集解決方案之外，您還可以使用 DH2i DxEnterprise 作為其中一個群集解決方案。 此選項可為您提供復原點目標 (RPO) 與復原時間目標 (RTO)，與高可用性解決方案預期會提供的一樣。

基於 Linux 的虛擬機部署

Linux 可搭配 SQL Server 在 Linux Azure 虛擬機上部署。 與本地部署一樣，支援的安裝需要使用圍欄保護一個位於叢集代理本身外部的失敗節點。 節點隔離是透過隔離可用性代理程式提供。 有些發行版本會將 STONITH 隨附於平台提供，而其他則仰賴外部硬體與軟體廠商來提供。 請洽詢您偏好的 Linux 發行版，以瞭解提供哪些形式的節點隔離，以便可以在公有雲中部署支援的解決方案。

下列發行版本提供 Linux 上的 SQL Server 安裝指南：

• 快速入門：在 Red Hat 上安裝 SQL Server 並建立資料庫
• 快速入門：在 Ubuntu 上安裝 SQL Server 並建立資料庫
• 快速入門：在 SUSE Linux Enterprise Server 上安裝 SQL Server 並建立資料庫

讀取比例

次要複本能夠用於唯讀查詢。 透過AG，有兩種方式可以達成：

• 允許直接存取次要系統
• 設定只讀路由，這需要使用監聽器。 SQL Server 2016 (13.x) 引進了使用循環配置資源演算法，透過接聽程式為唯讀連線進行負載平衡的功能，允許唯讀要求散佈到所有可讀取複本。

注意

可讀的次要副本僅在企業版中提供。 每個承載可讀副本的實例都需要 SQL Server 授權。

透過 AG 擴展可讀資料庫副本，最早是在 SQL Server 2016（13.x）中隨分散式 AG 引入的。 此功能不僅在本地提供資料庫的唯讀副本，也可在區域及全球範圍內提供，且配置極簡。 此配置透過讓查詢在本地執行，減少網路流量與延遲。 每個 AG 的主要副本可以初始化兩個其他 AG，即使它不是完全可讀寫的副本，且每個分散式 AG 最多可支援 27 個可讀的資料副本。

在 SQL Server 2017 （14.x） 和更新版本中，您可以使用設定為 None 叢集類型的 AG 來建立近乎即時的唯讀解決方案。 如果你的目標是使用 AG 來做可讀的次級副本，而不是可用性，這種做法可以省去使用 WSFC 或 Linux 上外部叢集解決方案的複雜性。 它以更簡單的部署方式，提供了 AG 的可讀性優勢。

唯一主要的注意事項是，由於沒有底層叢集類型為 None 的叢集，設定唯讀路由會有些不同。 從 SQL Server 的觀點來看，即使沒有叢集，仍需要接聽程式才能路由傳送要求。 與其設定傳統監聽器，不如使用主副本的 IP 位址或名稱。 主副本然後會導向唯讀請求。

從技術上講，可以透過還原資料庫 WITH STANDBY來配置日誌傳送暖待命資料庫以供讀取使用。 不過，由於交易記錄需要獨佔資料庫來進行還原，這表示在此情況下，使用者無法存取資料庫。 這會使記錄傳送略遜於理想的解決方案，特別是當需要近乎即時的資料時。

與交易複製中所有資料皆為活的複製不同，讀取規模情境下的每個次要副本都是主副本的完全複製。 副本目前尚未達到適用唯一索引的狀態。 如果報告需要索引或資料需要操作，你必須在主副本的資料庫上建立這些索引。 如果您需要這樣的彈性，複寫會是取得可讀取資料的較佳解決方案。

跨平台和 Linux 發行版本互通性

Windows Server 與 Linux 皆支援 SQL Server，本節將說明如何讓它們在可用性及其他用途上協同運作。 同時也涵蓋了整合多個 Linux 發行版的解決方案故事。

注意

沒有任何情境是基於 WSFC 的故障轉移叢集實例（FCI）或可用性群組（AG）能直接與基於 Linux 的 FCI 或 AG 協同運作。 Windows Server 故障轉移叢集（WSFC）無法由 Pacemaker 節點擴充，反之亦然。

分散式可用性群組

分散式 AG 的設計目的是跨越 AG 設定，無論 AG 下的那兩個基礎叢集是兩個不同的 WSFC、Linux 發行版本，或一個在 WSFC 而另一個位於 Linux。 分散式 AG 是實現跨平台解決方案的主要方式。 分散式 AG 也是用來移轉的主要解決方案，例如，假設貴公司希望將 SQL Server 基礎結構從採用 Windows Server 轉換為採用 Linux。 如前所述，AG，尤其是分散式AG，能將應用程式無法使用的時間降至最低。 下圖顯示跨越 WSFC 和 Pacemaker 的分散式 AG 範例：

如果你用叢集類型 None 配置 AG，它可以跨越 Windows Server 和 Linux，以及多個 Linux 發行版。 由於此配置並非真正的高可用性，請勿用於關鍵任務部署。 相反地，應該使用它來應對讀取擴展或遷移升級的場景。

記錄傳送

日誌的運送基於備份與還原，因此 SQL Server 在 Windows Server 與 Linux 上的 SQL Server 在資料庫、檔案結構及其他元素上並無差異。 你可以在 Windows Server 架構的 SQL Server 安裝與 Linux 版本之間設定日誌傳送，以及 Linux 發行版間的連線。 其他一切保持不變。

就像 AG 一樣，當來源伺服器使用較高版本的 SQL Server，而目標伺服器使用較低版本時，記錄傳送就無法運作。

摘要

你可以在 Windows Server 和 Linux 上使用相同功能，讓 SQL Server 2017（14.x）及更新版本的實例與資料庫變得高度可用。 除了標準的本地高可用性與災難復原情境外，您還可以透過 SQL Server 的可用性功能，將升級與遷移相關的停機時間降至最低。 AG 也可以在同一架構中提供額外的資料庫副本，以擴展可讀的副本。 無論是部署新的解決方案或考慮升級，SQL Server 都能為您提供所需的可用性與可靠性。

相關內容

• 什麼是 Always On 可用性群組？
• 安裝 SQL Server 故障轉移叢集