SQL Server 2017 高可用性

可用性功能的使用方式主要有如下四種:數據庫

  • 高可用性
  • 災難恢復
  • 遷移和升級
  • 擴大一個或多個數據庫的可讀副本

SQL Server 可用性功能不能替換對通過充分測試的可靠備份和還原策略的需求,後者是全部可用性解決方案最基本的構建基塊。異步

AlwaysOn 可用性組

SQL Server 2012 中引入的 AlwaysOn 可用性組將數據庫的每一個事務發送到另外一個實例,從而提供數據庫級別的保護,該實例稱爲副本,其中包含處於特定狀態的數據庫副本。測試

副本之間的數據移動能夠是同步的或異步的,Enterprise 版本容許同步多達三個副本(包括主要副本)。spa

AlwaysOn 是 SQL Server 中可用性功能的總稱,涵蓋可用性組和 FCI。 AlwaysOn 不是可用性組功能的名稱。3d

由於可用性組只提供數據庫級保護,而非實例級保護,因此須要爲每一個次要副本手動同步事務日誌中未捕獲的或數據庫中未配置的任何內容.日誌

就副本而言,Standard 版本和 Enterprise 版本具備不一樣的最大值。 Standard 版本中的可用性組(稱爲 Basic 可用性組)支持兩個副本(一個主要副本和一個次要副本),且可用性組中只有一個數據庫。 Enterprise 版本不只容許在一個可用性組中配置多個數據庫,並且擁有的副本總數可多達 9 個(1 個主要副本,8 個次要副本)。blog

 

REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT 的同步副本時執行何種操做的行爲。 該選項的工做原理以下所示:事務

  • 有三種可能的值:0、1 和 2
  • 值是必須同步的次要副本數,它對數據丟失、可用性組可用性和故障轉移都有影響
  • 對於 WSFC 和羣集類型爲「無」的狀況,默認值爲 0,可手動設置爲 1 或 2
  • 對於羣集類型爲「外部」的狀況,該值默認由羣集機制設置,並可手動重寫。 對於三個同步副本,默認值爲 1。 在 Linux 上,REQUIRED SYNCHRONIZED SECONDARIES_TO_COMMIT 的值在羣集中的可用性組資源上配置。 在 Windows 上,則經過 Transact-SQL 設置。

大於 0 的值可確保更高的數據保護程度,由於若是沒法得到所需的次要副本數,那麼在該問題解決以前,主要副本不可用。 REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT 還影響故障轉移行爲,由於若是適當數量的次要副本未處於正確狀態,則不會發生自動故障轉移。 在 Linux 上,若該值爲 0 則不容許自動故障轉移,所以在 Linux 上結合使用同步與自動故障轉移時,該值必須設置爲大於 0 才能實現自動故障轉移。 在 Windows Server 上將該值設置爲 0 是 SQL Server 2016 和更早版本的行爲。資源

 SQL Server 2017 對此進行了完善,對如下兩種狀況都提供 DTC 支持。同步

  • 在同一 SQL Server 實例中跨越多個數據庫的事務
  • 跨越多個 SQL Server 實例或可能涉及非 SQL Server 數據源的事務

 

下面的列表突出顯示了 Windows Server 與 Linux 上的 FCI 之間存在的一些差別:

  • 在 Windows Server 上,FCI 屬於安裝過程。 而 Linux 上的 FCI 則是在 SQL Server 安裝完成後配置。
  • Linux 僅支持每一個主機安裝一個 SQL Server,所以全部 FCI 都是默認實例。 Windows Server 支持每一個 WSFC 具備最多 25 個 FCI。
  • Linux 中 FCI 使用的公用名在 DNS 中定義,而且名稱應與爲 FCI 建立的資源相同。

日誌傳送

日誌傳送過程自動生成事務日誌備份,並將其複製到一個或多個稱爲熱備用狀態的實例,而後自動將事務日誌備份應用於該備用實例;

能夠說,在某種程度上使用日誌傳送的最大優勢在於它會考慮人爲錯誤。 事務日誌的應用可能會延遲。 所以,若是有人在沒有 WHERE 子句的狀況下發出相似 UPDATE 的內容,則備用可能還沒有更改,如此即可在修復主系統時切換到該備用實例。

跨數據中心;

AlwaysOn 可用性組

相關文章
相關標籤/搜索