商務持續性與資料庫復原 - SQL Server
適用於 
SQL Server 2016 (13.x) 和更新版本
本文提供適用於 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 的新功能
- Linux 上的 SQL Server 2017 新功能
- SQL Server 2019 的新功能
- Linux 上的 SQL Server 2019 新功能
- SQL Server 2022 中的新功能 (部分機器翻譯)
此文章的重點為說明 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 重新整理所耗費的時間。
災害復原
當主要可用性位置發生重大事件，例如水災或地震時，企業必須準備讓系統在其他地方上線。 本節會討論 SQL Server 可用性功能如何協助企業持續營運。
可用性群組
AG 的優點之一是能夠使用單一功能設定高可用性和災害復原。 在無須確保共用儲存體也高度可用的情況下，更容易就能在一個資料中心內擁有用於高可用性的複本，並在其他資料中心擁有用於災害復原的遠端複本，且每個複本都有各自的儲存體。 擁有額外的資料庫複本是確保備援需做出的取捨。 下方顯示的是跨越多個資料中心的 AG 範例。 一個主要複本負責保存所有同步處理的次要複本。
在叢集類型為「無」的 AG 外部，AG 會要求所有複本都屬於相同的基礎叢集，無論其為 WSFC 或外部叢集解決方案。 這表示在上圖中，WSFC 會延伸到在兩個不同的資料中心內運作，進而提升複雜度。 無論平台 (Windows Server 或 Linux)。 跨距離延展叢集會增加複雜性。
SQL Server 2016 (13.x) 引進的分散式可用性群組，能讓一個 AG 跨越不同叢集的多個 AG 進行設定。 分散式 AG 可分離所有節點參與相同叢集的需求，讓災害復原的設定更容易。 如需分散式 AG 的詳細資訊，請參閱分散式可用性群組 (部分機器翻譯)。
容錯移轉叢集執行個體
FCI 可用於災害復原。 與一般 AG 相同，基礎叢集機制也必須延伸到所有位置，進而提升複雜度。 FCI 有其他考量：共用儲存體。 在主要站台與次要站台中都必須能夠使用相同的磁碟。 若要確保其他地方也存在 FCI 所使用的磁碟，則需要使用外部方法，例如儲存體廠商在硬體層提供的功能，或在 Windows Server 中使用儲存體複本。
記錄傳送
記錄傳送是提供 SQL Server 資料庫災害復原最古老的方法之一。 記錄傳送通常與 AG 和 FCI 搭配使用，以提供具成本效益且更簡單的災害復原，災害復原的其他選項可能會因環境、管理技能或預算而十分困難。 類似記錄傳送的高可用性案例，許多環境會延遲載入交易記錄備份以考量人為錯誤。
移轉與升級
企業無法容許在部署新執行個體或升級舊執行個體時發生長時間的中斷。 本節將討論如何使用 SQL Server 可用性功能，將計劃的架構變更、伺服器切換、平台變更 (例如 Windows Server 換成 Linux，或反之) 或修補期間的停機時間降到最低。
注意
其他方法，例如使用備份和還原至其他地方，也可以用於移轉與升級。 此文章不會討論這些方法。
可用性群組
包含一或多個 AG 的現有執行個體可以就地升級到 SQL Server 的較新版本。 雖然這項作業需要一定程度的停機時間，但只要有正確的時間規劃，就可降至最低。
如果目標是要移轉到新的伺服器且不變更設定 (包括作業系統或 SQL Server 版本)，那些伺服器就可以新增為現有基礎叢集的節點，並新增至 AG。 只要一或多個複本處於正確的狀態，即可手動容錯移轉至新的伺服器，接著從 AG 中移除舊的伺服器，最終停止使用那些舊伺服器。
分散式 AG 也是移轉至新組態或升級 SQL Server 的另一種方法。 因為分散式 AG 可在不同架構上支援不同的基礎 AG；例如，您可以從在 Windows Server 2012 R2 上執行的 SQL Server 2016 (13.x) 變更成在 Windows Server 2016 上執行的 SQL Server 2017 (14.x)。
最後，叢集類型為「無」的 AG 也可以用於移轉或升級。 您不能在一般 AG 設定中混用不同的叢集類型，因此所有複本的類型都必須是「無」。 分散式 AG 可用來跨越設有不同叢集類型的 AG。 這個方法在各種不同的作業系統平台上也受到支援。
用於移轉和升級的所有 AG 變體都允許在一段時間內完成工作中最耗時的部分，也就是資料同步。 要起始切換至新的組態時，相對於需要完成包括資料同步處理在內所有工作的長時間停機，完全移轉中斷服務的時間較短。
AG 會在修補作業完成期間將主要複本手動容錯移轉至次要複本，以將修補基礎 OS 期間的停機時間降至最低。 從作業系統的觀點而言，在 Windows 伺服器上這樣做更常見，因為提供服務給基礎作業系統，通常 (但非一律) 需要重新開啟。 修補 Linux 有時候需要重新開機，但不常見。
修補參與可用性群組的 SQL Server 執行個體 (部分機器翻譯) 也能將停機時間降至最低，視 AG 架構的複雜程度而定。 若要修補參與 AG 的伺服器，必須先修補次要複本。 修補完成正確的複本數目後，主要複本即可手動容錯移轉至另一個要升級的節點。 任何剩餘的次要複本也可以在此時升級。
容錯移轉叢集執行個體
只有 FCI 本身無法協助傳統的移轉或升級；必須針對 FCI 中的資料庫或所有其他相關的物件設定 AG 或記錄傳送。 不過，基礎的 Windows Server 需要修補時，Windows Server 下的 FCI 仍是大受歡迎的選項。 您可以起始手動容錯移轉，這表示會有短暫中斷，而不是在修補 Windows Server 的整個期間都無法使用執行個體。 FCI 可就地升級到較新版本的 SQL Server。 如需相關資訊，請參閱升級 SQL Server 容錯移轉叢集執行個體。
記錄傳送
記錄傳送仍然是移轉和升級資料庫的熱門選項。 與 AG 相似，但這次是將交易記錄當作同步處理方法使用，在切換伺服器前讓資料傳播可以妥善開始。 在切換的同時，一旦所有流量都停在來源，就需要採用、複製最後一個交易記錄，並將它套用至新的組態。 此時，資料庫就可以上線了。 記錄傳送通常比較能容忍速度較慢的網路，而切換時間可能會比使用 AG 或分散式 AG 略長，通常以分鐘計 (非以小時、天或週計)。
與 AG 相似，記錄傳送可以提供在修補時切換到另一部伺服器的方式。
其他 SQL Server 部署方法和可用性
Linux 的 SQL Server 另有兩種部署方法：容器和使用 Azure (或其他公用雲端提供者)。 如本文所述的一般可用性需求，無論 SQL Server 部署方式為何都存在。 當要讓 SQL Server 具有高可用性時，這兩個方法有一些特殊考量。
SQL Server 容器與 HA/DR 選項
SQL Server 容器部署 (部分機器翻譯) 是部署 Linux 上的 SQL Server 的新方式。 容器是準備好要執行的 SQL Server 完整影像。
取決於您使用的容器平台 (例如使用 Kubernetes 等容器協調器)，當容器遺失時，可以再次部署並連結至先前使用的共用儲存體。 雖然這提供了某種程度的復原能力，但仍會有一些因資料庫復原而造成的停機時間，而且如果使用可用性群組或 FCI，也不會如預期般高度可用。
若您希望為部署在 Kubernetes 或非 Kubernetes 平台的 SQL Server 容器設定高可用性，除了可以在高可用性模式中設定 AG 的群集解決方案之外，您還可以使用 DH2i DxEnterprise 作為其中一個群集解決方案。 此選項可為您提供復原點目標 (RPO) 與復原時間目標 (RTO)，與高可用性解決方案預期會提供的一樣。
Linux 型 IaaS 部署
Linux IaaS 虛擬機器的部署可以使用 Azure 安裝 SQL Server。 與內部部署型安裝相同，支援的安裝需要使用位於叢集代理程式外部的 STONITH (Shoot the Other Node in the Head)。 STONITH 是透過隔離可用性代理程式提供。 有些發行版本會將 STONITH 隨附於平台提供，而其他則仰賴外部硬體與軟體廠商來提供。 請查看您慣用的 Linux 發行版本，了解所提供的 STONITH 格式為何，以便在公用雲端中部署支援的解決方案。
下列發行版本提供 Linux 上的 SQL Server 安裝指南：
- 快速入門：在 Red Hat 上安裝 SQL Server 並建立資料庫
- 快速入門：在 Ubuntu 上安裝 SQL Server 並建立資料庫
- 快速入門：在 SUSE Linux Enterprise Server 上安裝 SQL Server 並建立資料庫
讀取擴展
自從次要複本在 SQL Server 2012 (11.x) 引進後，就已經能夠用於唯讀查詢。 有兩種方式可透過 AG 達成：允許直接存取次要複本，以及設定唯讀路由 (部分機器翻譯) (必須使用接聽程式)。 SQL Server 2016 (13.x) 引進了使用循環配置資源演算法，透過接聽程式為唯讀連線進行負載平衡的功能，允許唯讀要求散佈到所有可讀取複本。
注意
可讀取次要複本是 Enterprise Edition 的獨有功能，每個裝載可讀取複本的執行個體都需要 SQL Server 授權。
透過 AG 調整資料庫的可讀取複本，是在 SQL Server 2016 (13.x) 的分散式 AG 中首度引進。 這可讓公司不僅在當地有資料庫的唯讀複本，還可以最少量的組態在地區及全球擁有資料庫的唯讀複本，且因為在本地執行查詢，而減少網路流量和延遲。 即使並非完整讀寫複本，AG 的每個主要複本皆可植入兩個其他 AG，因此每個分散式 AG 最多可以支援 27 份可讀取的資料。
自 SQL Server 2017 (14.x) 起，您即可在 AG 的叢集類型設定為「無」的情況下建立近乎即時的唯讀解決方案。 如果目標是使用 AG 取得可讀取次要複本，而非取得可用性，這樣做可消除使用 WSFC 或 Linux 上外部叢集解決方案的複雜性，並以較簡單的部署方法提供 AG 的可讀取優點。
最需要注意的是，由於沒有叢集類型為「無」的基礎叢集，設定唯讀路由的方式會略有不同。 從 SQL Server 的觀點來看，即使沒有叢集，仍需要接聽程式才能路由傳送要求。 使用 IP 位址或主要複本的名稱，而非設定傳統的接聽程式。 接著主要複本會用來路由傳送唯讀要求。
您可以還原資料庫 WITH STANDBY，針對可讀取使用方式技術性設定記錄傳送暖待命。 不過，由於交易記錄需要獨佔資料庫來進行還原，這表示在此情況下，使用者無法存取資料庫。 這會使記錄傳送略遜於理想的解決方案，特別是當需要近乎即時的資料時。
使用 AG 的所有讀取擴展案例都應注意，與使用所有資料皆為即時的異動複寫不同，每個次要複本都不會處於可套用唯一索引的狀態，且複本會與主要複本完全相符。 若有任何報告需要的索引，或是有任何需要操作的資料，都必須建立在主要複本上的資料庫中。 如果您需要這樣的彈性，複寫會是取得可讀取資料的較佳解決方案。
跨平台和 Linux 發行版本互通性
現在 Windows Server 與 Linux 都支援 SQL Server，此節會討論它們搭配運作以提供高可用性與用於其他用途的案例，以及討論會納入多個 Linux 發行版本的解決方案案例。
注意
沒有 WSFC 型 FCI 或 AG 會直接使用 Linux 型 FCI 或 AG 的案例。 Pacemaker 節點無法延伸 WSFC，反之亦然。
分散式可用性群組
分散式 AG 的設計目的是跨越 AG 設定，無論 AG 下的那兩個基礎叢集是兩個不同的 WSFC、Linux 發行版本，或一個在 WSFC 而另一個位於 Linux。 分散式 AG 是擁有跨平台解決方案的主要方法。 分散式 AG 也是用來移轉的主要解決方案，例如，假設貴公司希望將 SQL Server 基礎結構從採用 Windows Server 轉換為採用 Linux。 如上所述，AG (特別是分散式 AG) 可將應用程式無法使用的時間降至最低。 下方顯示的是跨 WSFC 與 Pacemaker 的分散式 AG 範例。
若 AG 是在叢集類型為「無」的情況下進行設定，則可跨越 Windows Server 與 Linux，以及多個 Linux 發行版本。 由於這並非真正的高可用性設定，因此不應用於任務關鍵性部署，但可用於讀取擴展或移轉/升級案例。
記錄傳送
由於記錄傳送以備份與還原作為基礎，因此 Windows Server 上的 SQL Server 與 Linux 上的 SQL Server 之間在資料庫、檔案結構等方面並無任何差異。 這表示記錄傳送可以在 Windows Server 型與 Linux 型 SQL Server 安裝之間設定，也可以在不同的 Linux 發行版本之間設定。 其他一切保持不變。 唯一需要注意的是，與 AG 一樣，當來源位在較高的 SQL Server 主要版本，而目標位於較低的 SQL Server 版本時，記錄傳送即無法運作。
摘要
在 Windows Server 與 Linux 上使用相同的功能，可讓 SQL Server 2017 (14.x) 與更新版本的執行個體與資料庫具備高可用性。 除了本機高可用性和災害復原的標準可用性案例外，SQL Server 的可用性功能可以將因升級和移轉所致的停機時間降到最低。 AG 也可以將資料庫的其他複本當作相同架構的一部分提供，以擴增可讀取複本。 無論是部署新的解決方案或考慮升級，SQL Server 都能為您提供所需的可用性與可靠性。