集群與事務複製與可用性組
假設您需要確保依賴 SQL Server 2012 作為其數據庫後端的應用程序全天候可用，即使一台伺服器機器出現故障。
作為開發人員而不是 DBA，我很難理解何時使用哪種方案來實現故障轉移/高可用性：
- Windows 故障轉移群集中的兩台（或更多）伺服器，SQL Server 作為群集實例
- 兩個（或更多）通過事務複製保持最新的 SQL Server 實例
- SQL Server 可用性組中的兩個（或更多）SQL Server，配置為同步送出模式
這些場景中的哪一個適用於什麼樣的工作負載，這些場景可以處理什麼樣的故障/中斷？它們甚至具有可比性/可交換性嗎？
我一直喜歡視覺化高可用性解決方案的方式如下：
SQL Server 故障轉移群集實例 (FCI)
什麼是高度可用的？ 整個實例。這包括所有伺服器對象（登錄、SQL Server 代理作業等）。這還包括數據庫及其包含實體。對於高度可用的 SQL Server 實例來說，這是一個很好的解決方案，因為這將是這個給定解決方案的包含級別。
報導呢？ 無，NULL，不存在。故障轉移集群實例有一個主動節點傳遞包含實例、VNN 等的集群組，而所有其他節點都是被動的，處於空閒狀態（就目前集群組而言）並等待故障轉移。
發生故障轉移時會發生什麼？ FCI 的停機時間將取決於被動節點獲取群集資源並使 SQL Server 實例處於執行狀態所需的時間。這通常是最小的時間。
任何客戶端抽象？ 是的，這將與故障轉移群集實例的虛擬網路名稱一起內置。這將始終指向目前提供 SQL Server 群集資源的活動節點。
AlwaysOn 可用性組
什麼是高度可用的？ 可用性組在這裡將成為高可用性的邏輯包含，而可用性組由許多數據庫和一個虛擬網路名稱（偵聽器，可選的群集資源）組成。值得注意的是，登錄和 SQL Server 代理作業等伺服器對像不會成為 HA 解決方案的一部分，需要特別考慮以確保通過可用性組正確實施這些對象。不是一個過度負擔的要求，但需要照顧。
**報導呢？**這是一個很好的報告解決方案，儘管我可能不會使用同步副本作為我的報告實例。有兩種送出關係，同步和非同步。在我看來，從我在實踐中看到的情況來看，您的同步輔助副本在那裡等待災難。將其視為準備好在出現問題時進行無數據失去故障轉移的副本。然後有可以處理該報告工作負載的非同步副本。您沒有將此副本用作上述解決方案，而是用於報告之類的事情。報告工作負載可以指向此副本（直接或間接通過偵聽器的只讀路由）。
發生故障轉移時會發生什麼？ 對於與自動故障轉移配對的同步送出輔助副本，這將是副本角色狀態從 SECONDARY_NORMAL 更改為 PRIMARY_NORMAL。為了實現自動故障轉移，您需要有一個目前同步的同步輔助副本，並且實施的是靈活的故障轉移策略來確定實際上何時應該發生這種故障轉移。該策略確實是可配置的。
任何客戶端抽象？ 是的，您可以選擇配置 AlwaysOn 可用性組偵聽器。這基本上只是一個指向目前主副本的虛擬網路名稱（通過 WSFC 可以看出是 AG 的集群組中的集群資源）。這是轉移您的報告工作負載的關鍵部分，以及在您想要重定向 ReadOnly 流量的任何伺服器上設置只讀路由列表（這是通過連接字元串設置的，使用 .NET Framework Provider for SQL伺服器，這將是Application Intent參數，設置為ReadOnly）。您還需要為要在輔助副本角色中接收此報告工作負載的每個副本設置只讀路由 URL。
事務複製
什麼是高度可用的？ 這是有爭議的，但我不會說什麼。我不認為複制是一種高可用性解決方案。是的，數據修改正在推送給訂閱者，但我們是在出版物/文章級別進行討論。這將是數據的一個子集（可以包括所有數據，但不會強制執行。即您在發布者數據庫中創建一個新表，並且不會自動推送給訂閱者）。就 HA 而言，這是最底層的，我不會將它與堅如磐石的 HA 解決方案組合在一起。
報導呢？ 報告數據子集的絕佳解決方案，毫無疑問。如果您有一個高度事務性的 1 TB 數據庫，並且您希望將報告工作負載從 OLTP 數據庫中排除，那麼事務複製是將數據子集推送到報告工作負載的訂閱者（或訂閱者）的好方法。如果在這 1 TB 的數據中，您的報告工作負載只有大約 50 GB，會發生什麼情況？這是一個智能解決方案，並且相對可配置以滿足您的業務需求。
概括
歸結為一些需要回答的問題（部分由企業回答）：
- 什麼需要高度可用？
- SLA對 HA/DR 有何規定？
- 將進行什麼樣的報告以及可接受的延遲時間？
- 對於地理位置分散的HA ，我們需要處理什麼？（儲存複製很昂貴，但必須使用 FCI。AG 不需要來自獨立實例的共享儲存，您可以使用文件共享見證進行仲裁，從而可能消除對共享儲存的需求）