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

發行項
07/15/2024

適用於：SQL Server

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

大眾部署 SQL Server 時都必須考量的一項工作，是確定所有任務關鍵性 SQL Server 執行個體及其內部資料庫，在企業和使用者需要它們時都能夠使用，無論是上班時間或全天候。目標是維持企業運轉不中斷或將影響降至最低。此概念也就是所謂的「商務持續性」。

SQL Server 2017 (14.x) 引進了許多新功能或現有項目的增強功能，其中有部分即是針對可用性推出。 SQL Server 2017 (14.x) 最主要新增的功能是 Linux 發行版本的 SQL Server 支援。如需 SQL Server 新增功能的完整清單，請參閱下列文章：

此文章的重點為說明 SQL Server 2017 (14.x) 與更新版本的可用性案例，以及新增與增強的可用性功能。這些案例包含可將 SQL Server 部署延伸至 Windows Server 與 Linux 的混合式案例，以及能夠提升資料庫可讀取複本數量的案例。

雖然此文章並未涵蓋 SQL Server 外部的可用性選項，例如由虛擬化提供的可用性選項，但這裡討論的所有內容都適用於客體虛擬機器內的 SQL Server 安裝，無論是位於公用雲端中或由內部部署 Hypervisor 伺服器所裝載皆是如此。

使用可用性功能的 SQL Server 案例

Always On 可用性群組、Always On 容錯移轉叢集執行個體以及記錄傳送都有多種運用方式，並非只供可用性使用。可用性功能有四個主要的使用方式：

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

下列各節會討論可用於該特定案例的相關功能。未涵蓋的一項功能是 SQL Server 複寫。 SQL Server 複寫雖未正式指定為 Always On 範圍內的可用性功能，但經常用於特定情況下的資料備援。 Linux 上的 SQL Server 不支援合併式複寫。如需詳細資訊，請參閱 Linux 上的 SQL Server 複寫 (部分機器翻譯)。

重要

SQL Server 可用性功能不會取代任何可用性方案對強固且經過備份和還原策略測試的最基本建置組塊的需求。

高可用性

如果資料中心所在地或雲端的單一區域發生問題，則確保 SQL Server 執行個體或資料庫可以使用就十分重要。此節會說明 SQL Server 可用性功能如何協助該工作。文中所述的所有功能皆可在 Windows Server 與 Linux 上使用。

可用性群組

可用性群組 (AG) 在 SQL Server 2012 (11.x) 中引進，可提供資料庫層級的保護，方式是將資料庫的每筆交易傳送至另一個執行個體，或稱「複本」，其中包含的該資料庫複本會處於特殊狀態。 AG 可部署於 Standard Edition 或 Enterprise Edition。參與 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) 起，除了執行個體層級以外，您還可以在 AG 層級管理中繼資料物件，包含使用者、登入、權限與 SQL Server Agent 作業。如需詳細資訊，請參閱自主可用性群組 (部分機器翻譯)。

AG 還有稱為「接聽程式」的另一個元件，其讓應用程式與終端使用者無需知道裝載主要複本的是哪個 SQL Server 執行個體，即可進行連線。每個 AG 都會有自己的接聽程式。雖然接聽程式在 Windows Server 與 Linux 上的實作略有不同，但提供的功能與使用方式相同。下圖顯示使用 Windows Server 容錯移轉叢集 (WSFC) 的 Windows Server 型 AG。無論是在 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 版，或 4.0 和更新版本)，就應該能夠在使用接聽程式的情況下處理容錯移轉，且幾乎或完全不會對使用者造成影響。容錯移轉至次要複本使其成為新主要複本的作業可以設定成自動或手動進行，而且通常以秒計。

下列清單強調了 Windows Server 和 Linux 上 AG 的一些差異：

由於基礎叢集在 Linux 和 Windows Server 上運作的方式有所差異，Linux 上 AG 的所有容錯移轉 (手動或自動) 都會透過叢集來完成。在 Windows Server 型 AG 部署上，手動容錯移轉必須透過 SQL Server 來完成。自動容錯移轉是由 Windows Server 和 Linux 上的基礎叢集控制。
針對 Linux 上的 SQL Server，AG 的建議設定為至少三個複本。這是由於基礎叢集的運作方式。
在 Linux 上，每個接聽程式使用的通用名稱是在 DNS 中定義，不像 Windows Server 是在叢集中。

自 SQL Server 2017 (14.x) 起，AG 有一些新功能和增強功能：

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

可用性群組叢集類型

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

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 名稱) 抽象化的元件。 DNS 在 Linux 上提供該名稱解析。

叢集堆疊中的差異導致 AG 必須進行某些變更，因為 SQL Server 必須處理部分由 WSFC 原生處理的中繼資料。這類顯著變更的其中一個是為可用性群組導入「叢集類型」。這會儲存在 cluster_type 與 cluster_type_desc 資料行中的 sys.availability_groups。有三種叢集類型：

WSFC
外部
None

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

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

重要

自 SQL Server 2017 (14.x) 起，您無法在 AG 建立後變更其叢集類型。這表示 AG 無法從 [無] 切換到 [外部] 或 [WSFC]，反之亦然。

當使用者只想新增資料庫的更多唯讀複本，或是希望使用 AG 針對移轉/升級所提供的功能，但又不想受限於基礎叢集或甚至複寫額外帶來的複雜度時，叢集類型為「無」的 AG 是最理想的解決方案。如需詳細資訊，請參閱移轉與升級及讀取級別等章節。

下列螢幕擷取畫面顯示對 SQL Server Management Studio (SSMS) 中不同種類叢集類型的支援。您必須執行版本 17.1 或更新版本。下列螢幕擷取畫面取自 17.2 版本。

REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT

SQL Server 2016 (13.x) 對 Enterprise Edition 的同步複本數目支援，從兩個增加到三個。不過，如果一個次要複本已同步處理，但另一個卻發生問題，沒有辦法控制行為以通知主要複本去等候行為異常的複本或允許它繼續。這表示在某些時候，即便次要複本並非處於同步狀態 (這代表次要複本上發生資料遺失的情況)，主要複本仍會繼續接收寫入流量。自 SQL Server 2017 (14.x) 起，您可以控管當 REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT 的同步複本出現時會發生的行為。此選項的運作方式如下：

可能的值有三個：0、1 與 2
值指的是必須同步的次要複本數目，這對資料遺失、AG 可用性與容錯移轉都有影響
針對 WSFC 與「無」叢集類型，預設值為 0，而且可以手動設定為 1 或 2
根據預設，若叢集類型為「外部」，叢集機制即會設定此值，而且可手動覆寫。針對三個同步複本，預設值將會是 1。

在 Linux 上，會在叢集中的 AG 資源上設定 REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT 的值。在 Windows 中，該值則會透過 Transact-SQL 進行設定。

若無法使用所需的次要複本數量，在解決該問題前，主要複本都無法使用，因此高於 0 的值可確保資料受到更好的保護。 REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT 也會影響容錯移轉行為，原因是若沒有數量正確的次要複本處於適當的狀態，即無法進行自動容錯移轉。在 Linux 上，值為 0 時不允許進行自動容錯移轉，因此若要在 Linux 上搭配自動容錯移轉使用同步，值必須設定為大於 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) 與更新版本中，DTC 支援也可以在 AG 建立後新增至 AG。在 SQL Server 2016 (13.x) 中，只有在建立 AG 時才能將 DTC 支援新增至 AG。

容錯移轉叢集執行個體

叢集安裝自 6.5 版起即為 SQL Server 功能。 FCI 是可為稱之為執行個體的整個 SQL Server 安裝，提供可用性的經證實方法。這表示萬一基礎伺服器發生問題，執行個體內的所有項目 (包括資料庫、SQL Server Agent 作業、連結的伺服器等) 都會移至另一部伺服器。所有 FCI 都需要某種類型的共用儲存體，即使該共用儲存體是透過網路提供也是如此。無論任何時候，FCI 的資源都只能由一個節點執行及擁有。在下圖中，第一個叢集節點擁有 FCI，這也代表該節點擁有與其相關聯的共用儲存體資源，這點在圖中以連至儲存體的實線表示。

容錯移轉叢集執行個體的圖表。

容錯移轉之後，所有權變更如下圖所示。

容錯移轉後的容錯移轉叢集執行個體圖表。

使用 FCI 時，不會遺失任何資料，但基礎共用儲存體為單一失敗點，因為有一份資料複本。 FCI 通常會結合 AG 或記錄傳送等其他可用性方法，以擁有備援的資料庫複本。額外部署的方法應該使用和 FCI 實體分隔的儲存體。當 FCI 容錯移轉到另一個節點時，其會在一個節點上停止，然後在另一個節點上啟動，與關閉再開啟伺服器電源沒什麼不同。 FCI 通過一般復原程序，表示會回復需要向前復原的任何交易，以及不完整的任何交易。因此，資料庫和失敗或手動容錯移轉時間點的資料是一致的，因此不會遺失資料。資料庫只有在復原完成後才可以使用，因此復原時間會取決於許多因素，且通常會比容錯移轉 AG 的時間長。相對地，當您容錯移轉 AG 時，可能需要進行其他工作才能使資料庫可用，例如啟用 SQL Server Agent 作業。

如同 AG，FCI 會將其裝載所在的基礎叢集節點抽象化。 FCI 一律保留相同的名稱。應用程式和使用者永遠不會連線到節點。使用指派給 FCI 的唯一名稱。 FCI 可以參與 AG，作為其中一個裝載主要或次要複本的執行個體。

下列清單會強調 Windows Server 和 Linux 上 FCI的一些差異：

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

記錄傳送

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

記錄傳送的圖表。

在某些容量中使用記錄傳送的最大優點，可以說是考量人為錯誤。套用交易記錄檔可予延遲。因此，如果有人發出類似不含 WHERE 子句的 UPDATE 這樣的內容，待命可能不會變更，而您無法在修復主要系統時切換至該待命。雖然記錄傳送很容易設定，但從主要切換到暖待命，也稱為角色變更，一律為手動。角色變更會透過 Transact-SQL 起始，而且與 AG 相同，交易記錄中未擷取的所有物件都必須手動進行同步。記錄傳送也需要按資料庫逐一設定，而單一 AG 可包含多個資料庫。

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