AlwaysOn 2016 新特性和提升

AlwaysOn 2016 新特性和提升

AlwaysOn可用性組作為SQL Server 2012的新特性被引入，它增強了數(shù)據(jù)庫鏡像和故障轉移集群技術，提供了高可用和災難恢復。

在SQL Server 2016中AlwaysOn有些特性的增強要求運行在Windows Server 2016上。然而，如果你仍然運行在Windows Server 2012 R2上，仍然有很多提升是可用的。

AlwaysOn 2016一些新特性和增強：

• l 支持更多故障轉移目標

• l 更好的日志傳輸性能

• l 可讀副本的負載均衡

• l 支持DTC

• l 數(shù)據(jù)庫級別的健康監(jiān)控

• l 支持組管理的服務賬號

• l 基本可用性組

• l 無域可用性組

• l 分布式可用性組

• l 支持加密數(shù)據(jù)庫

• l 支持SSIS目錄

• l BI增強

支持更多故障轉移目標

在AlwaysOn 2012和2014，允許最多只能配置2個副本作為自動故障轉移副本（包括當前主副本在內），2016允許配置3個。

自動故障轉移通常用于支持高可用，在故障轉移中同步數(shù)據(jù)流接近零數(shù)據(jù)丟失。

更好的日志傳輸性能

隨著高速硬件SSD的普遍使用，提供了更大的吞吐量，這對于寫事務到輔助副本是很重要的。因此，微軟更新了AlwaysOn的數(shù)據(jù)同步過程，簡化了管道以便有更好的吞吐量和CPU上的更少壓力。性能瓶頸大多數(shù)可能發(fā)生在日志捕獲（Log Capture）和重做（Redo）步驟。之前，日志捕獲和重做步驟使用單線程處理日志，而現(xiàn)在這些步驟使用多線程并行運行，極大提升了性能。

數(shù)據(jù)同步描述如下：

Transaction Occurs –> Log Flush –> Log Capture –> Send –> Log Received –> Log Cached –> Log Hardened –> Acknowledgement Sent –> Redo

可讀副本的負載均衡

AlwaysOn一個很棒的特性是能夠使用輔助副本用于只讀操作。在AlwaysOn 2016之前的版本，監(jiān)聽器會定向只讀請求到第一個可用副本，即便你可能有多個輔助副本，并且你可能設置路由表優(yōu)先將度請求定向到副本3或副本4，而不是副本2。現(xiàn)在AlwaysOn 2016的可讀副本以輪詢的形式暴露給監(jiān)聽器。

1.配置輔助副本的只讀訪問

ALTER AVAILABILITY GROUP [ag]
MODIFY REPLICA ON N'SQL16N2' WITH (SECONDARY_ROLE(ALLOW_CONNECTIONS = READ_ONLY))
GO
ALTER AVAILABILITY GROUP [ag]
MODIFY REPLICA ON N'SQL16N3' WITH (SECONDARY_ROLE(ALLOW_CONNECTIONS = READ_ONLY))
GO

2.配置只讀路由URL

ALTER AVAILABILITY GROUP ag MODIFY REPLICA ON N'SQL16N2' WITH (SECONDARY_ROLE (READ_ONLY_ROUTING_URL = N'TCP://SQL16N2:1433'));
GO
ALTER AVAILABILITY GROUP ag MODIFY REPLICA ON N'SQL16N3' WITH (SECONDARY_ROLE (READ_ONLY_ROUTING_URL = N'TCP://SQL16N3:1433'));
GO

3.SQL Server 2016在只讀路由列表中引入了負載均衡列表

當SQL16N1為主副本角色時，創(chuàng)建只讀路由列表：

ALTER AVAILABILITY GROUP ag MODIFY REPLICA ON N'SQL16N1' WITH (PRIMARY_ROLE (READ_ONLY_ROUTING_LIST=(('SQL16N3', 'SQL16N2'), 'SQL16N1')));

以上路由列表表示在SQL16N3和SQL16N2之間負載均衡只讀連接。我們有兩個嵌入列表：

List 1: 'SQL16N3', 'SQL16N2'

List 2: 'SQL16N1'

按如下方式工作：

1. 路由到第一個列表中的副本

SQL16N3和SQL16N2對只讀連接是可訪問的。第一個只讀連接被路由到SQL16N3，第二個只讀連接被路由到SQL16N2，第三個只讀連接被路由到SQL16N3，第四個只讀連接被路由到SQL16N2，等等，在第一個列表的兩個副本之間使用一個只讀連接的輪詢分發(fā)。

2. 如果任一副本不可用了，路由將繼續(xù)在第一個列表的副本中

如果SQL16N3或者SQL16N2對于只讀連接變?yōu)椴豢稍L問，那么只讀連接將只被路由到第一個列表的可訪問只讀副本。例如，如果SQL16N3不是synchronized狀態(tài)，或者ALLOW_CONNECTIONS被設為NO，那么所有的只讀連接將會被路由到SQL16N2。只要只讀連接的其中一個服務器可用，那么只讀連接就不會被路由到SQL16N1。

3. 如果第一個列表中的所有副本都不可訪問，將會路由到下一個列表

對于只讀連接，如果SQL16N3和SQL16N2變?yōu)椴豢稍L問，那么所有的只讀連接將只會被路由到下一個列表的副本，這里就是SQL16N1。

4. 如果第一個列表中的任一副本可用，將會恢復路由到第一個列表

因為對于只讀連接，可訪問的第一個列表中的輔助副本有更高的優(yōu)先級，后面的只讀連接將會恰當?shù)倪B接到他們。

此外配置可用性組路由列表，你也必須確保客戶端的應用連接串當連接到AG監(jiān)聽器時增加ApplicationIntent參數(shù)，值為ReadOnly。如果在客戶端應用連接串中沒有設置，那這個連接將自動定向到主副本。以下是只讀連接串的示例：

Server=tcp:AGListener,1433; Database=AdventureWorks;IntegratedSecurity=SSPI; ApplicationIntent=ReadOnly

也最好不要在相同的負載均衡組中混合同步和異步副本。

支持DTC

注：只有運行在Windows Server 2016或者升級了KB3090973補丁的Windows Server 2012 R2上

如果你的客戶端應用程序需要執(zhí)行跨多個實例的事務，那么就需要分布式事務協(xié)調器（DTC）。DTC是操作系統(tǒng)的一部分，當你的數(shù)據(jù)庫引擎執(zhí)行跨多個實例的事務時，用于確保一致性。

USE AdventureWorks2012;
GO
BEGIN DISTRIBUTED TRANSACTION;
-- your tsql statement here
DELETE FROM AdventureWorks2012.HumanResources.JobCandidate
WHERE JobCandidateID = 13;
GO
COMMIT TRANSACTION;
GO

你的應用程序不僅可以在多個SQL Server實例間執(zhí)行事務，也可以在其他兼容DTC服務器中，像WebSphere或Oracle。

用于 AlwaysOn 可用性組和數(shù)據(jù)庫鏡像的跨數(shù)據(jù)庫事務和分布式事務。

https://msdn.microsoft.com/en-us/library/mt748186.aspx https://blogs.technet.microsoft.com/dataplatform/2016/01/25/sql-server-2016-dtc-support-in-availability-groups/

https://docs.microsoft.com/zh-cn/sql/database-engine/availability-groups/windows/transactions-always-on-availability-and-database-mirroring?view=sql-server-2017

為了能在AlwaysOn 2016中執(zhí)行分布式事務，可用性組創(chuàng)建語句CREATE AVAILABILITY GROUP帶有WITH DTC_SUPPORT = PER_DB從句。

CREATE AVAILABILITY GROUP AGSQL2016
WITH (DTC_SUPPORT = PER_DB)
FOR DATABASE [Database1, Database2, Database3]
REPLICA ON
'SQLSRVTST1' WITH — substitute node name
(
ENDPOINT_URL = 'TCP://SQLSRVTST1.<domain>:7022',
AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
FAILOVER_MODE = AUTOMATIC
),
'SQLSRVTST2' WITH — substitute node name
(
ENDPOINT_URL = 'TCP://SQLSRVTST2.<domain>:7022',
AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
FAILOVER_MODE = AUTOMATIC
);
GO

數(shù)據(jù)庫級別的健康監(jiān)控

在之前的AlwaysOn 2012和2014中，如果實例健康出現(xiàn)問題，將觸發(fā)故障轉移。如果有一個數(shù)據(jù)庫有問題，只要實例OK，可用性組就不會故障轉移。因此，如果你有一個數(shù)據(jù)庫掉線、異?；驌p壞，也不會觸發(fā)故障轉移。

在AlwaysOn 2016中，不論是一個實例有問題，還是一個或多個數(shù)據(jù)庫有問題，都會發(fā)生故障轉移。然而，這不是默認設置。在創(chuàng)建可用組配置向導，你可以選擇“Database Level Health Detection”復選框來指定。對應的創(chuàng)建可用性組的參數(shù)為DB_FAILOVER = ON

對于什么情況下觸發(fā)數(shù)據(jù)庫故障轉移，你也可以調整FailureConditionLevel屬性設置。根據(jù)需要調整默認值。可以參考：https://msdn.microsoft.com/en-us/library/ff878667.aspx

支持組管理的服務賬號

在SQL Server 2012，微軟添加了組管理的服務賬號增強，以便服務賬號密碼可以更容易管理。你現(xiàn)在可以為你的SQL Server實例創(chuàng)建一個獨立的服務賬號，在AD中管理密碼、分配代理權限給每個服務器。這個特性對AlwaysOn AG是有用的，因為密碼和訪問特定資源像共享文件的權限，可以通過一個賬號管理，而不是每個實例獨立配置。在AlwaysOn AG中使用組管理的服務賬號比使用通常的域用戶賬號更加安全。

參考：

https://docs.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/group-managed-service-accounts-overview

https://blogs.msdn.microsoft.com/markweberblog/2016/05/25/group-managed-service-accounts-gmsa-and-sql-server-2016/

基本可用性組

AlwaysOn基本可用性組在SQL Server 2016標準版中可用。功能與數(shù)據(jù)庫鏡像一樣，而數(shù)據(jù)庫鏡像已經被廢棄，會在將來的版本中被移除?；究捎眯越M提供了單個數(shù)據(jù)庫的故障轉移，在組內只可以有兩個副本，數(shù)據(jù)同步可以是同步或異步模式，在輔助副本不提供只讀訪問和備份支持。創(chuàng)建基本可用性組，可以使用CREATE

AVAILABILITY GROUP語句帶有WITH BASIC從句。
CREATE AVAILABILITY GROUP BAGSQL2016
WITH (AUTOMATED_BACKUP_PREFERENCE = PRIMARY,
BASIC,
DB_FAILOVER = OFF,
DTC_SUPPORT = NONE)
FOR DATABASE [Database1, Database2, Database3]
REPLICA ON
'SQLSRVTST1' WITH -- substitute node name
(
ENDPOINT_URL = ‘TCP://SQLSRVTST1.<domain>.com:5022’,
FAILOVER_MODE = AUTOMATIC,
AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
SECONDARY_ROLE (ALLOW_CONNECTIONS = NO)
),
'SQLSRVTST2' WITH -- substitute node name
(
ENDPOINT_URL = ‘TCP://SQLSRVTST2.<domain>.com:5022’,
FAILOVER_MODE = AUTOMATIC,
AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
SECONDARY_ROLE (ALLOW_CONNECTIONS = NO)
)
GO

參考：

https://blogs.technet.microsoft.com/msftpietervanhove/2017/03/14/top-5-questions-about-basic-availability-groups/

無域可用性組

注：只可運行在Windows Server 2016上

大多數(shù)公司運行在單一域環(huán)境，而有些公司運行在多個域環(huán)境，可以部署跨多個域的可用性組，以便多臺服務器可以作為DR副本。而有些組織根本沒有運行在域環(huán)境。

Windows Server 2016中，WSFC不需要集群節(jié)點在相同的域，或者根本不需要域（可以在工作組）。SQL Server 2016現(xiàn)在可以在以下環(huán)境部署AlwaysOn可用性組：

• l 所有節(jié)點在單一域

• l 節(jié)點在多個完全信任的域

• l 節(jié)點在多個不信任的域

• l 節(jié)點不在域中

通過去掉集群的域約束，提升了靈活性。參考：https://blogs.msdn.microsoft.com/clustering/2015/08/17/workgroup-and-multi-domain-clusters-in-windows-server-2016/

分布式可用性組

分布式可用性組，可將AlwaysOn AG跨兩個不同的WSFC，來擴展AG。

分布式 AG 也是另一種遷移到新配置或升級 SQL Server 的方法。 因為分布式 AG 在不同體系結構上支持不同的基礎 AG，例如，可以從在 Windows Server 2012 R2 上運行的 SQL Server 2016 更改為在 Windows Sever 2016 上運行的 SQL Server 2017。

參考：

https://docs.microsoft.com/en-us/sql/database-engine/availability-groups/windows/distributed-availability-groups

支持加密數(shù)據(jù)庫

在之前版本AlwaysOn允許加密數(shù)據(jù)庫，然而他們不能通過新建可用性組添加，并且如果切換到輔助副本他們不能被訪問。在SQL Server 2016，可以通過向導添加加密數(shù)據(jù)庫，并且在故障轉移后可以訪問。這是因為，在創(chuàng)建可用性組時，向導對于每個副本執(zhí)行了sp_control_dbmasterkey_password，并且使用每個實例的數(shù)據(jù)庫主秘鑰創(chuàng)建了憑據(jù)。在故障轉移后SQL Server會搜索正確的憑據(jù)，知道可以解密數(shù)據(jù)庫主秘鑰。

關于添加加密數(shù)據(jù)庫到AlwaysOn可用性組有些限制。參考：https://docs.microsoft.com/en-us/sql/database-engine/availability-groups/windows/encrypted-databases-with-always-on-availability-groups-sql-server?view=sql-server-2017

支持SSIS目錄

在SQL Server 2016，你可以像其它數(shù)據(jù)庫一樣，為了增強高可用和災難恢復，添加SSIS目錄（SSISDB）和它的內容（項目、包等）到AlwaysOn可用性組。

對于添加SSISDB到AlwaysOn可用性組有些特定的先決條件和配置，參考：https://docs.microsoft.com/en-us/sql/integration-services/catalog/ssis-catalog?view=sql-server-2017#always-on-for-ssis-catalog-ssisdb

BI增強

使用AlwaysOn可用性組，數(shù)據(jù)庫倉庫負載指向一個或者多個可讀輔助副本，而主副本用于支持關鍵業(yè)務應用。報表和數(shù)據(jù)分析是資源密集型應用，因此負載指向非生產服務器可以提高整體性能。另一個增強點是，微軟優(yōu)化了數(shù)據(jù)同步進程，在數(shù)據(jù)倉庫數(shù)據(jù)同步延時非常低，以致近實時分析成為現(xiàn)實。

結論

最新版的AlwaysOn可用性組提升了功能性、可擴展性、可管理性，并在高可用和災難恢復上更加健壯。