SQL Server AlwaysON从入门到进阶（6）——分析和部署AlwaysOn Availability Group
生活随笔
收集整理的這篇文章主要介紹了
SQL Server AlwaysON从入门到进阶（6）——分析和部署AlwaysOn Availability Group
小編覺得挺不錯的,現(xiàn)在分享給大家,幫大家做個參考.
本文屬于SQL Server AlwaysON從入門到進(jìn)階系列文章
AlwaysOn可用組（下稱AG）是將數(shù)據(jù)庫的全部內(nèi)容復(fù)制到一組預(yù)定義的SQL Server伙伴實例中，也稱副本，用于備用或只讀訪問。這個功能通過創(chuàng)建一個包含最少兩個副本和最少一個數(shù)據(jù)庫的AlwaysOn可用組來實現(xiàn)。每個數(shù)據(jù)庫僅能屬于一個AG，但是副本之間可以有多個AG。每當(dāng)創(chuàng)建一個新組并添加數(shù)據(jù)庫時，會有一系列的預(yù)校驗操作。如下圖：（注意，某些圖是作者原圖，在后續(xù)部署過程中會使用本人實操的截圖）
在數(shù)據(jù)庫參與到AlwaysOn可用組之前，必須滿足這些先決條件。完整的先決條件列表可以看：針對 AlwaysOn 可用性組的先決條件、限制和建議 (SQL Server)。然后我們就可以復(fù)制數(shù)據(jù)庫到一組預(yù)定義伙伴實例中，用于讀取連接。 但是，AG也有一些限制：
詳細(xì)內(nèi)容可以參考：活動次要副本：可讀次要副本（AlwaysOn 可用性組）
盡管有所限制，AlwaysOn還是提供了一個新層次的高可用功能：
這一步需要重啟SQL Server實例。
下面先在前面提到的5個節(jié)點中都安裝SQL Server，注意相同版本。在啟用了AlwaysOn組之后，可以開始部署了。我們使用的是獨立安裝SQL Server。為了速度，這里使用命令行安裝SQL Server。具體詳見：從命令提示符安裝 SQL Server 2014 加載完安裝文件之后，在cmd命令中，切換當(dāng)前盤符到安裝文件所在的盤，本例是D盤。然后輸入以下命令執(zhí)行即可，注意要有足夠的權(quán)限。安裝之后需要檢查一下是否合符條件，當(dāng)然要是覺得麻煩也可以用圖形化安裝，只是交互操作略多。
如果用圖形化界面安裝請勾選上圖部分
另外，為了后續(xù)的批量操作，也先把所有服務(wù)器添加到注冊服務(wù)器中，注意關(guān)閉防火墻：
然后把SQL Server配置管理器中的AlwaysON 可用組開啟：
然后還原微軟示例數(shù)據(jù)庫AdventureWorks2014。然后在clusternode1的SSMS中，選擇“AlwaysOn高可用性”→右鍵下一級文件夾的“可用性組”→【新建可用性組向?qū)А?#xff1a;
第一個界面：顯示了完成一次可用性組配置所需的內(nèi)容。如果是第一次搭建，請先檢查是否滿足要求
注意：除此之外，你還需要跟相應(yīng)的管理人員獲取足夠的賬號信息、虛擬網(wǎng)絡(luò)名和虛擬IP地址。
接下來定義一個AlwaysOn可用性組名。這個名字會成為在WSFC內(nèi)創(chuàng)建的群集名，并且群集內(nèi)必須唯一，然后選擇下一步：
然后會看到下圖，為了繼續(xù)進(jìn)行，先手工修改恢復(fù)模式然后對數(shù)據(jù)庫做一次完整備份，然后刷新一下： ：
刷新之后就變成下圖：
在【指定副本】對話框中，可以看到向?qū)б呀?jīng)幫你初始化了當(dāng)前的SQL Server實例。在這里可以添加副本，也必須添加1~4（SQL 2012）/8（SQL 2014）個副本。
最后配置會是下圖樣子，但是目前，我們先不使用自動故障轉(zhuǎn)移，接下來點開【端點】選項頁：
下面開始端點的配置，如果你使用默認(rèn)賬號安裝和配置SQL Server服務(wù)，可以看到下面端點配置：另外注意默認(rèn)使用的端口號是5022（跟數(shù)據(jù)庫鏡像使用的一樣，但是可以改變）
當(dāng)通過SQL Server配置管理器變更SQL Server服務(wù)帳號（比如改成localsystem），再在這個界面刷新并點下一步的時候就會出現(xiàn)下圖的警告：
為了方便搜索引擎搜索，下面把文字貼出： 中文：
“端點”選項卡列出至少一個僅使用 Windows 身份驗證的端點。但是，該服務(wù)器實例可能正以某一非域帳戶運行。若要使用列出的端點，請將相應(yīng)的 SQL Server 服務(wù)帳戶更改為域帳戶。若要繼續(xù)使用該非域帳戶，請更改該端點以便使用證書。
是否要使用列出的端點?
英文：The Endpoints tab lists at least one endpoint that uses only Windows Authentication. However, the server instance might be running under a nondomain account.?To use the listed endpoint, change the corresponding SQL Server service account to a domain account. To continue using the nondomain account, alter the endpoint to use a certificate.?Do you want to use the listed endpoints?
對于這種警告，通常有兩種方式：最合理：各節(jié)點使用同一個域賬號啟動SQL Server，可以使用較低權(quán)限的域用戶賬號。 權(quán)宜之計：在有些情況下，賬號并非隨你操作，所以你可以使用類似語句授權(quán)： GRANT CONNECT ON endpoint::hadr_endpoint
TO [domain\servername$] 如果沒有端點，你還要手動創(chuàng)建：CREATE ENDPOINT [Hadr_endpoint]STATE=STARTEDAS TCP (LISTENER_PORT = 5022, LISTENER_IP = ALL)FOR DATA_MIRRORING (ROLE = ALL
, AUTHENTICATION = WINDOWS NEGOTIATE
, ENCRYPTION = REQUIRED ALGORITHM AES)
但是基于很多原因，還是盡量使用相同的、有足夠權(quán)限的域賬號進(jìn)行配置。關(guān)于這部分的內(nèi)容可以查閱官方文檔：可用性組偵聽器和服務(wù)器主體名稱 (SPN)
必須由域管理員在 Active Directory 中為每個可用性組偵聽器名稱配置服務(wù)器主體名稱 (SPN)，才能為到可用性組偵聽器的客戶端連接啟用 Kerberos。 注冊 SPN 時，必須使用托管可用性副本的服務(wù)器實例的服務(wù)帳戶。 對于跨所有副本工作的 SPN，必須為承載可用性組的 WSFC 群集中的所有實例使用相同的服務(wù)帳戶。
使用 Windows 命令行工具?setspn?配置 SPN。 例如，要為一組 SQL Server 實例上承載的名為?AG1listener.Adventure-Works.com?的可用性組配置 SPN，所有實例都應(yīng)被配置為在域帳戶?corp/svclogin2下運行：setspn -A MSSQLSvc/AG1listener.Adventure-Works.com:1433 corp/svclogin2
接下來是【備份首選項】，如下圖：
在這里可以選擇備份操作發(fā)生在什么副本中。這里我希望選擇節(jié)點4作為備份用的副本，可以像上圖那樣把排除副本勾選。然后轉(zhuǎn)到【偵聽器】頁。 在【偵聽器】頁，選擇之前配置好的偵聽器。如果之前沒創(chuàng)建，可以在這里創(chuàng)建，但是必須是唯一的虛擬網(wǎng)絡(luò)名，TCP端口和虛擬IP地址（如果沒有使用DHCP）。然后添加靜態(tài)IP。接下來選擇【添加】。最后選擇【下一步】。
在【選擇數(shù)據(jù)同步】界面中，選擇符合條件的同步模式，前面演示過，在初始化次要數(shù)據(jù)庫時，需要做完整備份和日志備份。由于前面已經(jīng)做了，所以這里選擇【僅聯(lián)接】。下面簡單解釋一下：
然后點擊下一步。在【驗證】對話框中會看到類似下圖樣子：
在沒有報錯的情況下，點擊下一步并完成創(chuàng)建AlwaysON可用性組的配置：
完成之后可以查看結(jié)果，如無問題可以點擊關(guān)閉，配置完成之后可以看到下圖樣子：
到目前為止，AlwaysON組已經(jīng)成功創(chuàng)建。檢查WSFC的配置，可以看到一個新的群集角色和資源分配。這里的AlwaysON群集角色表名，有一個AlwaysON組和一個已群集的AlwaysON資源，使用的是在部署向?qū)е卸x的名字。對于偵聽器，我們分配了一個已群集的虛擬網(wǎng)絡(luò)名和虛擬IP地址。需要注意的是截至到SQL 2014為止，AlwaysON都要求所有參與節(jié)點基于同一個群集，因為如果不在同一個群集，那么在發(fā)生故障轉(zhuǎn)移的時候，又怎么轉(zhuǎn)移群集資源呢？ 注意：不要嘗試去手動修改組的首選所有者或資源的可能所有者列表。任何這種修改都是徒勞無功的，因為這些在故障轉(zhuǎn)移過程中，依賴于副本配置，會動態(tài)變更AlwaysON組的群集配置。
如果想查詢當(dāng)前AlwaysON組的主副本，可以使用下面的PowerShell命令實現(xiàn)： get-clusterresource -cluster "WindowsClusterName" | where-object{$_.ResourceType -ilike "SQL Server Availability Group"} | ft
注意替換上面的WindowsClusterName。 在完成之后，我們可以使用SSMS的界面進(jìn)行手動故障轉(zhuǎn)移，或者使用下面的腳本進(jìn)行手動故障轉(zhuǎn)移：
ALTER AVAILABILITY GROUP [YourAG] FAILOVER
ALTER AVAILABILITY GROUP [STOKEAG_1] MODIFY REPLICA ON N'STOKECSCLNODE1\INST1' WITH (SECONDARY_ROLE (ALLOW_CONNECTIONS = READ_ONLY));ALTER AVAILABILITY GROUP [STOKEAG_1] MODIFY REPLICA ON N'STOKECSCLNODE1\INST1' WITH (SECONDARY_ROLE (READ_ONLY_ROUTING_URL = N'TCP://stokecsclnode1.stokecs2.co.uk:58001'));ALTER AVAILABILITY GROUP [STOKEAG_1] MODIFY REPLICA ONN'STOKECSCLNODE2\INST1' WITH (SECONDARY_ROLE (ALLOW_CONNECTIONS = READ_ONLY));ALTER AVAILABILITY GROUP [STOKEAG_1] MODIFY REPLICA ON N'STOKECSCLNODE2\INST1' WITH (SECONDARY_ROLE (READ_ONLY_ROUTING_URL = N'TCP://stokecsclnode2.stokecs2.co.uk:58001'));ALTER AVAILABILITY GROUP [STOKEAG_1] MODIFY REPLICA ONN'STOKECSCLNODE3\INST1' WITH (SECONDARY_ROLE (ALLOW_CONNECTIONS = READ_ONLY));ALTER AVAILABILITY GROUP [STOKEAG_1] MODIFY REPLICA ONN'STOKECSCLNODE3\INST1' WITH (SECONDARY_ROLE (READ_ONLY_ROUTING_URL = N'TCP://stokecsclnode3.stokecs2.co.uk:58001'));
比如我本機(jī)環(huán)境改成：
ALTER AVAILABILITY GROUP GeorgeAG MODIFY REPLICA ONN'CLUSTERNODE1' WITH (SECONDARY_ROLE (ALLOW_CONNECTIONS = READ_ONLY));ALTER AVAILABILITY GROUP GeorgeAG MODIFY REPLICA ONN'CLUSTERNODE1' WITH (SECONDARY_ROLE (READ_ONLY_ROUTING_URL = N'TCP://CLUSTERNODE1.george.com:1433'));ALTER AVAILABILITY GROUP GeorgeAG MODIFY REPLICA ONN'CLUSTERNODE2' WITH (SECONDARY_ROLE (ALLOW_CONNECTIONS = READ_ONLY));ALTER AVAILABILITY GROUP GeorgeAG MODIFY REPLICA ONN'CLUSTERNODE2' WITH (SECONDARY_ROLE (READ_ONLY_ROUTING_URL = N'TCP://CLUSTERNODE2.george.com:1433'));ALTER AVAILABILITY GROUP GeorgeAG MODIFY REPLICA ONN'CLUSTERNODE3' WITH (SECONDARY_ROLE (ALLOW_CONNECTIONS = READ_ONLY));ALTER AVAILABILITY GROUP GeorgeAG MODIFY REPLICA ONN'CLUSTERNODE3' WITH (SECONDARY_ROLE (READ_ONLY_ROUTING_URL = N'TCP://CLUSTERNODE3.george.com:1433'));
下一步是指定在每個副本在作為主角色的時候路由首選項：
ALTER AVAILABILITY GROUP [STOKEAG_1] MODIFY REPLICA ON N'STOKECSCLNODE1\INST1' WITH (PRIMARY_ROLE (READ_ONLY_ROUTING_LIST = ('STOKECSCLNODE3\INST1', 'STOKECSCLNODE2\INST1', 'STOKECSCLNODE1\INST1')));ALTER AVAILABILITY GROUP [STOKEAG_1] MODIFY REPLICA ON N'STOKECSCLNODE2\INST1' WITH (PRIMARY_ROLE (READ_ONLY_ROUTING_LIST = ('STOKECSCLNODE3\INST1', 'STOKECSCLNODE1\INST1', 'STOKECSCLNODE2\INST1')));ALTER AVAILABILITY GROUP [STOKEAG_1] MODIFY REPLICA ON N'STOKECSCLNODE3\INST1' WITH (PRIMARY_ROLE (READ_ONLY_ROUTING_LIST = ('STOKECSCLNODE2\INST1', 'STOKECSCLNODE1\INST1', 'STOKECSCLNODE3\INST1')));
本機(jī)改成：
ALTER AVAILABILITY GROUP GeorgeAG MODIFY REPLICA ON N'CLUSTERNODE1' WITH (PRIMARY_ROLE (READ_ONLY_ROUTING_LIST = ('CLUSTERNODE3', 'CLUSTERNODE2', 'CLUSTERNODE1')));ALTER AVAILABILITY GROUP GeorgeAG MODIFY REPLICA ON N'CLUSTERNODE2' WITH (PRIMARY_ROLE (READ_ONLY_ROUTING_LIST = ('CLUSTERNODE3', 'CLUSTERNODE1', 'CLUSTERNODE2')));ALTER AVAILABILITY GROUP GeorgeAG MODIFY REPLICA ON N'CLUSTERNODE3' WITH (PRIMARY_ROLE (READ_ONLY_ROUTING_LIST = ('CLUSTERNODE2', 'CLUSTERNODE1', 'CLUSTERNODE3')));
最后一段代碼配置每個指定的副本的主角色，包括你想分?jǐn)傌?fù)載到read intent所需要連接的副本。通常需要配置所有的副本，但是也并不是強(qiáng)制的。如果指定了所有副本，理想情況下主副本應(yīng)該作為路由列表的最后一個連接。術(shù)語“READ_ONLY_ROUTING_LIST”是從左到右枚舉，優(yōu)先級也是從左到右。 現(xiàn)在只讀路由列表已經(jīng)配置完成，可以通過偵聽器測試。主副本是節(jié)點1，然后使用一個SQLCMD并帶有意向只讀去查詢，可以看到當(dāng)前實例名是節(jié)點三。
只讀路由配置看上去跟之前會有點混亂。實際上，一旦你確定需要的副本，那么這個腳本是很容易配置的。但是要注意的是，只讀URL是數(shù)據(jù)庫引擎本身的URL。不是數(shù)據(jù)庫鏡像端口URL或偵聽器URL。
現(xiàn)在在CLUSTERNODE1中打開“故障轉(zhuǎn)移群集管理器”可以看到以下截圖：
然后通過Hyper-V控制臺，把ClusterNode3這臺虛擬機(jī)的網(wǎng)卡設(shè)為“未連接”，再在ClusterNode1中刷新故障轉(zhuǎn)移群集管理器的界面，可以看到下圖：
CLUSTERNODE1已經(jīng)變成了主副本。同時群集管理器中的角色所有者也變成了CLUSTERNODE1。如果沒做任何干預(yù)就能實現(xiàn)上圖情況，那證明自動故障轉(zhuǎn)移沒有問題。然后我們把NODE3的網(wǎng)卡恢復(fù)。
當(dāng)主副本出現(xiàn)故障并切換到同步或異步副本時，會被要求確認(rèn)故障轉(zhuǎn)移向?qū)н^程中，必須接受數(shù)據(jù)丟失的風(fēng)險。然后選擇作為主副本的副本進(jìn)行接收事務(wù)。但是如果失敗的話怎么回滾？原理是什么？ 在這個測試中，把可用性組全部設(shè)為非自動故障轉(zhuǎn)移模式，然后在當(dāng)前主副本（NODE1）中關(guān)閉SQLSERVR.EXE進(jìn)程，模擬軟件故障，此時AlwaysON會變成Resolving狀態(tài)，由于這個時候沒有自動故障轉(zhuǎn)移的伙伴副本存在，所以這種情況下主副本的故障是災(zāi)難性的。 接下來，在Node4中，作為異步同步的副本，進(jìn)行強(qiáng)制故障轉(zhuǎn)移，在轉(zhuǎn)移過程中，向?qū)嵝涯銜袧撛诘臄?shù)據(jù)丟失風(fēng)險。 先把AlwaysON配置成以下樣子：
然后在NODE1中的任務(wù)管理器中終止SQL Server進(jìn)程：
終止進(jìn)程之后看到主節(jié)點已經(jīng)失敗：
切換到NODE4，可以看到當(dāng)前的可用性組的狀態(tài)為“正在解析”：
在NODE4中的可用性組，右鍵選擇故障轉(zhuǎn)移，可以看到下面嘆號：
下一步中有明確的數(shù)據(jù)丟失風(fēng)險警告：
轉(zhuǎn)移成功后，可以看到NODE4中的狀態(tài)變成了“主要”：
同時，在故障轉(zhuǎn)移群集管理器中可以看到所有者節(jié)點現(xiàn)在也變成餓了ClusterNode4：
從顯示面板看，其他節(jié)點均為“未同步”狀態(tài)：
最后我們可以看到次要副本的數(shù)據(jù)庫是暫停狀態(tài)的，也就是掛起了數(shù)據(jù)移動：
右鍵數(shù)據(jù)庫選擇“”：
在同步完畢之后，數(shù)據(jù)就變得無丟失。
有個值得看一下的現(xiàn)象，在故障轉(zhuǎn)移過程中的群集角色的資源狀態(tài)。當(dāng)把AlwaysOn組故障轉(zhuǎn)移到一個手動同步的節(jié)點時，會修改首選群集角色的所有者到這個節(jié)點上。此外在 AlwaysOn 資源上的可能所屬者的列表也設(shè)置為只有該節(jié)點。比如，下面的情景。當(dāng)前的AlwaysOn組的主副本活動在節(jié)點1，而主副本是同步模式并且手動故障轉(zhuǎn)移。然后我們看看群集角色和AlwaysOn資源的所有者列表：
當(dāng)我們把主節(jié)點failover到NODE3之后，再檢查：
當(dāng)AlwaysOn設(shè)置為有同步副本且自動故障轉(zhuǎn)移之后，資源列表又變得不同了。這里重新設(shè)置NODE3/4兩個為同步、自動故障轉(zhuǎn)移，然后再次查看：
注意：這些屬性都是動態(tài)管理的，所以沒有必要干預(yù)。
前言：
本節(jié)是整個系列的重點文章，到現(xiàn)在，讀者應(yīng)該已經(jīng)對整個高可用架構(gòu)有一定的了解，知道獨立的SQL Server實例和基于群集的SQL Server FCI的區(qū)別。上一節(jié)已經(jīng)介紹了如何安裝SQL Server Failover Cluster Instance（FCI）及其要求。 本節(jié)會深入AlwaysOn 可用組的內(nèi)容，以演示部署為主線，包括如何啟用只讀路由和使用AlwaysOn組偵聽器。并在最后演示故障轉(zhuǎn)移。 在前面文章中對FCI和AlwaysOn可用組有了一定的平臺要求。這里對其進(jìn)行簡要的回顧。- Windows Server AD域
- DNS基礎(chǔ)設(shè)施
- DHCP（如需）
- Windows Server Failover Cluster（WSFC）
- WSFC上的節(jié)點
為什么使用AlwaysOn可用組？
在過去，通常會使用SQL Server FCI來實現(xiàn)SQL Server的高可用，這個要么基于Microsoft Cluster Services（Windows 2003）或WSFC（Windows 2008/2012）作為基礎(chǔ)。在群集中使用下面功能使得服務(wù)器在硬件故障時能夠完整遷移：- 多網(wǎng)卡及TCP/IP網(wǎng)絡(luò)用于網(wǎng)絡(luò)冗余。
- 新的多數(shù)節(jié)點集仲裁模型 （從?Windows server 2003 SP1 開始） 移除磁盤依賴項，并增加對多站點群集的支持。
- 使用多個計算機(jī)節(jié)點以抵消核心節(jié)點硬件故障（如主板等）。
什么是AlwaysOn可用組：
AlwaysOn可用組（下稱AG）是將數(shù)據(jù)庫的全部內(nèi)容復(fù)制到一組預(yù)定義的SQL Server伙伴實例中，也稱副本，用于備用或只讀訪問。這個功能通過創(chuàng)建一個包含最少兩個副本和最少一個數(shù)據(jù)庫的AlwaysOn可用組來實現(xiàn)。每個數(shù)據(jù)庫僅能屬于一個AG，但是副本之間可以有多個AG。每當(dāng)創(chuàng)建一個新組并添加數(shù)據(jù)庫時，會有一系列的預(yù)校驗操作。如下圖：（注意，某些圖是作者原圖，在后續(xù)部署過程中會使用本人實操的截圖）
在數(shù)據(jù)庫參與到AlwaysOn可用組之前，必須滿足這些先決條件。完整的先決條件列表可以看：針對 AlwaysOn 可用性組的先決條件、限制和建議 (SQL Server)。然后我們就可以復(fù)制數(shù)據(jù)庫到一組預(yù)定義伙伴實例中，用于讀取連接。 但是，AG也有一些限制：
- 副本數(shù)量：SQL 2012中最大5個：1主4次要副本。SQL 2014中為1主8次要共9個副本。
- 同步復(fù)制的設(shè)置：最大3個，其他副本只能使用異步模式。
- 自動故障轉(zhuǎn)移數(shù)量：最多2個，并且必須為同步模式。
行版本的影響：
當(dāng)啟用只讀的次要副本時，行版本會自動開啟并對每一樣添加14byte的標(biāo)識。實際上所有隔離級別都透明地映射到快照隔離級別從而避免重做線程阻塞。如果沒有這個，那么報表負(fù)載將受重做線程干擾。 主副本的行版本數(shù)據(jù)的添加依賴于主庫上的快照隔離級別或已提交讀快照隔離級別的設(shè)置。組中的庫如果使用了行版本控制，那么主副本上的也會有這方面的開銷（也就是比如組中多個庫只有一個庫使用了行版本存儲，那么整個副本都會受到影響）。 通過查詢“sys.dm_db_index_physical_stats”這個DMV中的“max_record_size_in_bytes”列，就可以看到這樣的開銷。下表描述了基于磁盤的表（非SQL 2014引入的內(nèi)存表）不同設(shè)置下，可讀副本數(shù)據(jù)庫的版本控制行為：| 否 | 否 | 無行版本或 14 個字節(jié)的系統(tǒng)開銷 | 無行版本或 14 個字節(jié)的系統(tǒng)開銷 |
| 否 | 是 | 行版本和 14 個字節(jié)的系統(tǒng)開銷 | 無行版本但有 14 個字節(jié)的系統(tǒng)開銷 |
| 是 | 否 | 無行版本但有 14 個字節(jié)的系統(tǒng)開銷 | 行版本和 14 個字節(jié)的系統(tǒng)開銷 |
| 是 | 是 | 行版本和 14 個字節(jié)的系統(tǒng)開銷 | 行版本和 14 個字節(jié)的系統(tǒng)開銷 |
詳細(xì)內(nèi)容可以參考：活動次要副本：可讀次要副本（AlwaysOn 可用性組）
缺少統(tǒng)計信息的影響：
任何可讀次要副本數(shù)據(jù)庫都會遇到缺少統(tǒng)計信息引起只讀負(fù)載相關(guān)的問題。所有在主庫上創(chuàng)建或更新的統(tǒng)計信息都會同步并駐留到次要數(shù)據(jù)庫中。所有運行在次要數(shù)據(jù)庫的負(fù)載會產(chǎn)生臨時統(tǒng)計信息并存儲在TempDB中。這樣會使得TempDB有潛在壓力。這也是對TempDB要細(xì)心監(jiān)控的原因之一。更多的信息可以看官方文檔：活動次要副本：可讀次要副本（AlwaysOn 可用性組）優(yōu)點：
盡管有所限制，AlwaysOn還是提供了一個新層次的高可用功能：
- 沒有共享存儲：每個服務(wù)器\實例都使用本地存儲，并且移除了共享存儲的單點故障風(fēng)險。
- AlwaysOn偵聽器服務(wù)用于接受集中請求到HA數(shù)據(jù)庫組。
- 多個可用可用數(shù)據(jù)庫取代了傳統(tǒng)的一主一備（往往是不可讀）。
- 更合理的Failover功能。
- 在副本層面掛起數(shù)據(jù)移動。
- 支持多IP子網(wǎng)。
- 可以把備份負(fù)載分?jǐn)偟酱我獢?shù)據(jù)庫。
這一步需要重啟SQL Server實例。
部署可用組：
下面先在前面提到的5個節(jié)點中都安裝SQL Server，注意相同版本。在啟用了AlwaysOn組之后，可以開始部署了。我們使用的是獨立安裝SQL Server。為了速度，這里使用命令行安裝SQL Server。具體詳見：從命令提示符安裝 SQL Server 2014 加載完安裝文件之后，在cmd命令中，切換當(dāng)前盤符到安裝文件所在的盤，本例是D盤。然后輸入以下命令執(zhí)行即可，注意要有足夠的權(quán)限。安裝之后需要檢查一下是否合符條件，當(dāng)然要是覺得麻煩也可以用圖形化安裝，只是交互操作略多。
如果用圖形化界面安裝請勾選上圖部分
另外，為了后續(xù)的批量操作，也先把所有服務(wù)器添加到注冊服務(wù)器中，注意關(guān)閉防火墻：
然后把SQL Server配置管理器中的AlwaysON 可用組開啟：
然后還原微軟示例數(shù)據(jù)庫AdventureWorks2014。然后在clusternode1的SSMS中，選擇“AlwaysOn高可用性”→右鍵下一級文件夾的“可用性組”→【新建可用性組向?qū)А?#xff1a;
第一個界面：顯示了完成一次可用性組配置所需的內(nèi)容。如果是第一次搭建，請先檢查是否滿足要求
注意：除此之外，你還需要跟相應(yīng)的管理人員獲取足夠的賬號信息、虛擬網(wǎng)絡(luò)名和虛擬IP地址。
接下來定義一個AlwaysOn可用性組名。這個名字會成為在WSFC內(nèi)創(chuàng)建的群集名，并且群集內(nèi)必須唯一，然后選擇下一步：
然后會看到下圖，為了繼續(xù)進(jìn)行，先手工修改恢復(fù)模式然后對數(shù)據(jù)庫做一次完整備份，然后刷新一下： ：
刷新之后就變成下圖：
在【指定副本】對話框中，可以看到向?qū)б呀?jīng)幫你初始化了當(dāng)前的SQL Server實例。在這里可以添加副本，也必須添加1~4（SQL 2012）/8（SQL 2014）個副本。
最后配置會是下圖樣子，但是目前，我們先不使用自動故障轉(zhuǎn)移，接下來點開【端點】選項頁：
下面開始端點的配置，如果你使用默認(rèn)賬號安裝和配置SQL Server服務(wù)，可以看到下面端點配置：另外注意默認(rèn)使用的端口號是5022（跟數(shù)據(jù)庫鏡像使用的一樣，但是可以改變）
當(dāng)通過SQL Server配置管理器變更SQL Server服務(wù)帳號（比如改成localsystem），再在這個界面刷新并點下一步的時候就會出現(xiàn)下圖的警告：
為了方便搜索引擎搜索，下面把文字貼出： 中文：
“端點”選項卡列出至少一個僅使用 Windows 身份驗證的端點。但是，該服務(wù)器實例可能正以某一非域帳戶運行。若要使用列出的端點，請將相應(yīng)的 SQL Server 服務(wù)帳戶更改為域帳戶。若要繼續(xù)使用該非域帳戶，請更改該端點以便使用證書。
是否要使用列出的端點?
英文：The Endpoints tab lists at least one endpoint that uses only Windows Authentication. However, the server instance might be running under a nondomain account.?To use the listed endpoint, change the corresponding SQL Server service account to a domain account. To continue using the nondomain account, alter the endpoint to use a certificate.?Do you want to use the listed endpoints?
對于這種警告，通常有兩種方式：
但是基于很多原因，還是盡量使用相同的、有足夠權(quán)限的域賬號進(jìn)行配置。關(guān)于這部分的內(nèi)容可以查閱官方文檔：可用性組偵聽器和服務(wù)器主體名稱 (SPN)
必須由域管理員在 Active Directory 中為每個可用性組偵聽器名稱配置服務(wù)器主體名稱 (SPN)，才能為到可用性組偵聽器的客戶端連接啟用 Kerberos。 注冊 SPN 時，必須使用托管可用性副本的服務(wù)器實例的服務(wù)帳戶。 對于跨所有副本工作的 SPN，必須為承載可用性組的 WSFC 群集中的所有實例使用相同的服務(wù)帳戶。
使用 Windows 命令行工具?setspn?配置 SPN。 例如，要為一組 SQL Server 實例上承載的名為?AG1listener.Adventure-Works.com?的可用性組配置 SPN，所有實例都應(yīng)被配置為在域帳戶?corp/svclogin2下運行：setspn -A MSSQLSvc/AG1listener.Adventure-Works.com:1433 corp/svclogin2
接下來是【備份首選項】，如下圖：
在這里可以選擇備份操作發(fā)生在什么副本中。這里我希望選擇節(jié)點4作為備份用的副本，可以像上圖那樣把排除副本勾選。然后轉(zhuǎn)到【偵聽器】頁。 在【偵聽器】頁，選擇之前配置好的偵聽器。如果之前沒創(chuàng)建，可以在這里創(chuàng)建，但是必須是唯一的虛擬網(wǎng)絡(luò)名，TCP端口和虛擬IP地址（如果沒有使用DHCP）。然后添加靜態(tài)IP。接下來選擇【添加】。最后選擇【下一步】。
在【選擇數(shù)據(jù)同步】界面中，選擇符合條件的同步模式，前面演示過，在初始化次要數(shù)據(jù)庫時，需要做完整備份和日志備份。由于前面已經(jīng)做了，所以這里選擇【僅聯(lián)接】。下面簡單解釋一下：
- FULL：完整，其字面解釋如下圖，這個選項要求完整和日志備份，并把備份還原到每個次要副本中。
- Join Only：僅聯(lián)接，已經(jīng)以【NORECOVERY】模式還原數(shù)據(jù)庫，這個選項直接把庫加入可用組中。
- Skip initial data synchronisation：跳過初始化數(shù)據(jù)同步，這個選項可以讓你在完成向?qū)е筮€原數(shù)據(jù)庫和把次要副本加入AlwaysON可用性組中。
然后點擊下一步。在【驗證】對話框中會看到類似下圖樣子：
在沒有報錯的情況下，點擊下一步并完成創(chuàng)建AlwaysON可用性組的配置：
完成之后可以查看結(jié)果，如無問題可以點擊關(guān)閉，配置完成之后可以看到下圖樣子：
到目前為止，AlwaysON組已經(jīng)成功創(chuàng)建。檢查WSFC的配置，可以看到一個新的群集角色和資源分配。這里的AlwaysON群集角色表名，有一個AlwaysON組和一個已群集的AlwaysON資源，使用的是在部署向?qū)е卸x的名字。對于偵聽器，我們分配了一個已群集的虛擬網(wǎng)絡(luò)名和虛擬IP地址。需要注意的是截至到SQL 2014為止，AlwaysON都要求所有參與節(jié)點基于同一個群集，因為如果不在同一個群集，那么在發(fā)生故障轉(zhuǎn)移的時候，又怎么轉(zhuǎn)移群集資源呢？ 注意：不要嘗試去手動修改組的首選所有者或資源的可能所有者列表。任何這種修改都是徒勞無功的，因為這些在故障轉(zhuǎn)移過程中，依賴于副本配置，會動態(tài)變更AlwaysON組的群集配置。
如果想查詢當(dāng)前AlwaysON組的主副本，可以使用下面的PowerShell命令實現(xiàn)： get-clusterresource -cluster "WindowsClusterName" | where-object{$_.ResourceType -ilike "SQL Server Availability Group"} | ft
注意替換上面的WindowsClusterName。 在完成之后，我們可以使用SSMS的界面進(jìn)行手動故障轉(zhuǎn)移，或者使用下面的腳本進(jìn)行手動故障轉(zhuǎn)移：
ALTER AVAILABILITY GROUP [YourAG] FAILOVER
配置只讀路由：
在創(chuàng)建完帶有偵聽器的AlwaysON可用性組之后，可以配置只讀路由以便更好地管理只讀請求。在把客戶端的意向只讀請求重定位之前，必須先創(chuàng)建一個偵聽器。然后配置只讀路由列表用于訪問AlwaysON副本。在上面的部署過程中已經(jīng)創(chuàng)建了偵聽器，所以現(xiàn)在可以開始配置只讀路由。下面的T-SQL代碼是用于在本機(jī)中配置，第一個代碼塊配置了一個次要角色用于可能被用來做只讀路由的各個副本之用。替換代碼中紅色部分，這些是SQL 實例名的路由URL，注意不是鏡像端點URL或者偵聽器URL：ALTER AVAILABILITY GROUP [STOKEAG_1] MODIFY REPLICA ON N'STOKECSCLNODE1\INST1' WITH (SECONDARY_ROLE (ALLOW_CONNECTIONS = READ_ONLY));ALTER AVAILABILITY GROUP [STOKEAG_1] MODIFY REPLICA ON N'STOKECSCLNODE1\INST1' WITH (SECONDARY_ROLE (READ_ONLY_ROUTING_URL = N'TCP://stokecsclnode1.stokecs2.co.uk:58001'));ALTER AVAILABILITY GROUP [STOKEAG_1] MODIFY REPLICA ONN'STOKECSCLNODE2\INST1' WITH (SECONDARY_ROLE (ALLOW_CONNECTIONS = READ_ONLY));ALTER AVAILABILITY GROUP [STOKEAG_1] MODIFY REPLICA ON N'STOKECSCLNODE2\INST1' WITH (SECONDARY_ROLE (READ_ONLY_ROUTING_URL = N'TCP://stokecsclnode2.stokecs2.co.uk:58001'));ALTER AVAILABILITY GROUP [STOKEAG_1] MODIFY REPLICA ONN'STOKECSCLNODE3\INST1' WITH (SECONDARY_ROLE (ALLOW_CONNECTIONS = READ_ONLY));ALTER AVAILABILITY GROUP [STOKEAG_1] MODIFY REPLICA ONN'STOKECSCLNODE3\INST1' WITH (SECONDARY_ROLE (READ_ONLY_ROUTING_URL = N'TCP://stokecsclnode3.stokecs2.co.uk:58001'));
比如我本機(jī)環(huán)境改成：
ALTER AVAILABILITY GROUP GeorgeAG MODIFY REPLICA ONN'CLUSTERNODE1' WITH (SECONDARY_ROLE (ALLOW_CONNECTIONS = READ_ONLY));ALTER AVAILABILITY GROUP GeorgeAG MODIFY REPLICA ONN'CLUSTERNODE1' WITH (SECONDARY_ROLE (READ_ONLY_ROUTING_URL = N'TCP://CLUSTERNODE1.george.com:1433'));ALTER AVAILABILITY GROUP GeorgeAG MODIFY REPLICA ONN'CLUSTERNODE2' WITH (SECONDARY_ROLE (ALLOW_CONNECTIONS = READ_ONLY));ALTER AVAILABILITY GROUP GeorgeAG MODIFY REPLICA ONN'CLUSTERNODE2' WITH (SECONDARY_ROLE (READ_ONLY_ROUTING_URL = N'TCP://CLUSTERNODE2.george.com:1433'));ALTER AVAILABILITY GROUP GeorgeAG MODIFY REPLICA ONN'CLUSTERNODE3' WITH (SECONDARY_ROLE (ALLOW_CONNECTIONS = READ_ONLY));ALTER AVAILABILITY GROUP GeorgeAG MODIFY REPLICA ONN'CLUSTERNODE3' WITH (SECONDARY_ROLE (READ_ONLY_ROUTING_URL = N'TCP://CLUSTERNODE3.george.com:1433'));
下一步是指定在每個副本在作為主角色的時候路由首選項：
ALTER AVAILABILITY GROUP [STOKEAG_1] MODIFY REPLICA ON N'STOKECSCLNODE1\INST1' WITH (PRIMARY_ROLE (READ_ONLY_ROUTING_LIST = ('STOKECSCLNODE3\INST1', 'STOKECSCLNODE2\INST1', 'STOKECSCLNODE1\INST1')));ALTER AVAILABILITY GROUP [STOKEAG_1] MODIFY REPLICA ON N'STOKECSCLNODE2\INST1' WITH (PRIMARY_ROLE (READ_ONLY_ROUTING_LIST = ('STOKECSCLNODE3\INST1', 'STOKECSCLNODE1\INST1', 'STOKECSCLNODE2\INST1')));ALTER AVAILABILITY GROUP [STOKEAG_1] MODIFY REPLICA ON N'STOKECSCLNODE3\INST1' WITH (PRIMARY_ROLE (READ_ONLY_ROUTING_LIST = ('STOKECSCLNODE2\INST1', 'STOKECSCLNODE1\INST1', 'STOKECSCLNODE3\INST1')));
本機(jī)改成：
ALTER AVAILABILITY GROUP GeorgeAG MODIFY REPLICA ON N'CLUSTERNODE1' WITH (PRIMARY_ROLE (READ_ONLY_ROUTING_LIST = ('CLUSTERNODE3', 'CLUSTERNODE2', 'CLUSTERNODE1')));ALTER AVAILABILITY GROUP GeorgeAG MODIFY REPLICA ON N'CLUSTERNODE2' WITH (PRIMARY_ROLE (READ_ONLY_ROUTING_LIST = ('CLUSTERNODE3', 'CLUSTERNODE1', 'CLUSTERNODE2')));ALTER AVAILABILITY GROUP GeorgeAG MODIFY REPLICA ON N'CLUSTERNODE3' WITH (PRIMARY_ROLE (READ_ONLY_ROUTING_LIST = ('CLUSTERNODE2', 'CLUSTERNODE1', 'CLUSTERNODE3')));
最后一段代碼配置每個指定的副本的主角色，包括你想分?jǐn)傌?fù)載到read intent所需要連接的副本。通常需要配置所有的副本，但是也并不是強(qiáng)制的。如果指定了所有副本，理想情況下主副本應(yīng)該作為路由列表的最后一個連接。術(shù)語“READ_ONLY_ROUTING_LIST”是從左到右枚舉，優(yōu)先級也是從左到右。 現(xiàn)在只讀路由列表已經(jīng)配置完成，可以通過偵聽器測試。主副本是節(jié)點1，然后使用一個SQLCMD并帶有意向只讀去查詢，可以看到當(dāng)前實例名是節(jié)點三。
只讀路由配置看上去跟之前會有點混亂。實際上，一旦你確定需要的副本，那么這個腳本是很容易配置的。但是要注意的是，只讀URL是數(shù)據(jù)庫引擎本身的URL。不是數(shù)據(jù)庫鏡像端口URL或偵聽器URL。
掛起數(shù)據(jù)移動：
這個功能需求是非常常見的，AlwaysON組提供在主次副本層面上對加入AlwaysON數(shù)據(jù)庫進(jìn)行數(shù)據(jù)移動掛起功能。在某些場景下會自動觸發(fā)這 種掛起。如果在AlwaysON環(huán)境下，主副本發(fā)生故障同時又沒有可用的“自動轉(zhuǎn)移”的次要副本，那么次要副本會進(jìn)入“Resolving（正在解析）”狀態(tài)，這時候就要使用手動或者強(qiáng)制故障轉(zhuǎn)移到一個異步同步副本中。當(dāng)執(zhí)行強(qiáng)制轉(zhuǎn)移時，數(shù)據(jù)移動就會自動變成掛起，這時候要重新連接到新的異步主副本的數(shù)據(jù)庫。這個在接下來的測試環(huán)節(jié)會看到。 注意：當(dāng)一個異步副本被強(qiáng)制作為主副本時，事務(wù)會發(fā)送到新的次要異步副本。 在主副本和次要副本之間掛起數(shù)據(jù)移動會停止數(shù)據(jù)同步。但是主副本的數(shù)據(jù)庫依舊聯(lián)機(jī)和可用。此時繁忙數(shù)據(jù)庫中的事務(wù)日志的增長就會成為隱患，所以在這種情況下要小心，哪怕配置合理。 在次要副本的數(shù)據(jù)移動掛起會使得其上面的數(shù)據(jù)庫狀態(tài)變成“未同步（Not Synchronising）”，并且次要數(shù)據(jù)庫會變成不可用。當(dāng)恢復(fù)數(shù)據(jù)移動以后在主副本的積壓的日志會繼續(xù)同步到次要數(shù)據(jù)庫并使得次要數(shù)據(jù)庫恢復(fù)可用。 小心另外一個引起數(shù)據(jù)移動掛起的情況，當(dāng)可用性組從SQL 2012的副本中轉(zhuǎn)移到一個高版本的副本，比如2014上時，和其他SQL Server高可用技術(shù)一樣，這種過程是不可逆的。不過這種方式可以用于數(shù)據(jù)庫從低版本遷移到高版本的情景。測試故障轉(zhuǎn)移場景和觀察結(jié)果：
下面來測試一下我們的環(huán)境是否可用。一方面是測試搭建有沒有問題，另外一方面也可以作為以后在正式環(huán)境中校驗的步驟。自動故障轉(zhuǎn)移：
允許自動故障轉(zhuǎn)移的前提是必須有最少兩個副本，且為同步模式，同時配置了自動故障轉(zhuǎn)移，否則只能使用手動故障轉(zhuǎn)移。在這里，使CLUSTERNODE3作為主副本，然后把CLUSTERNODE1作為同步、自動副本。然后把CLUSTERNODE3的網(wǎng)卡關(guān)閉，模擬硬件故障，然后理論上會發(fā)生自動故障轉(zhuǎn)移到CLUSTERNODE1中。現(xiàn)在在CLUSTERNODE1中打開“故障轉(zhuǎn)移群集管理器”可以看到以下截圖：
然后通過Hyper-V控制臺，把ClusterNode3這臺虛擬機(jī)的網(wǎng)卡設(shè)為“未連接”，再在ClusterNode1中刷新故障轉(zhuǎn)移群集管理器的界面，可以看到下圖：
CLUSTERNODE1已經(jīng)變成了主副本。同時群集管理器中的角色所有者也變成了CLUSTERNODE1。如果沒做任何干預(yù)就能實現(xiàn)上圖情況，那證明自動故障轉(zhuǎn)移沒有問題。然后我們把NODE3的網(wǎng)卡恢復(fù)。
手動和強(qiáng)制故障轉(zhuǎn)移：
當(dāng)主副本出現(xiàn)故障并切換到同步或異步副本時，會被要求確認(rèn)故障轉(zhuǎn)移向?qū)н^程中，必須接受數(shù)據(jù)丟失的風(fēng)險。然后選擇作為主副本的副本進(jìn)行接收事務(wù)。但是如果失敗的話怎么回滾？原理是什么？ 在這個測試中，把可用性組全部設(shè)為非自動故障轉(zhuǎn)移模式，然后在當(dāng)前主副本（NODE1）中關(guān)閉SQLSERVR.EXE進(jìn)程，模擬軟件故障，此時AlwaysON會變成Resolving狀態(tài)，由于這個時候沒有自動故障轉(zhuǎn)移的伙伴副本存在，所以這種情況下主副本的故障是災(zāi)難性的。 接下來，在Node4中，作為異步同步的副本，進(jìn)行強(qiáng)制故障轉(zhuǎn)移，在轉(zhuǎn)移過程中，向?qū)嵝涯銜袧撛诘臄?shù)據(jù)丟失風(fēng)險。 先把AlwaysON配置成以下樣子：
然后在NODE1中的任務(wù)管理器中終止SQL Server進(jìn)程：
終止進(jìn)程之后看到主節(jié)點已經(jīng)失敗：
切換到NODE4，可以看到當(dāng)前的可用性組的狀態(tài)為“正在解析”：
在NODE4中的可用性組，右鍵選擇故障轉(zhuǎn)移，可以看到下面嘆號：
下一步中有明確的數(shù)據(jù)丟失風(fēng)險警告：
轉(zhuǎn)移成功后，可以看到NODE4中的狀態(tài)變成了“主要”：
同時，在故障轉(zhuǎn)移群集管理器中可以看到所有者節(jié)點現(xiàn)在也變成餓了ClusterNode4：
從顯示面板看，其他節(jié)點均為“未同步”狀態(tài)：
最后我們可以看到次要副本的數(shù)據(jù)庫是暫停狀態(tài)的，也就是掛起了數(shù)據(jù)移動：
右鍵數(shù)據(jù)庫選擇“”：
在同步完畢之后，數(shù)據(jù)就變得無丟失。
在故障轉(zhuǎn)移過程中群集角色資源狀態(tài)：
有個值得看一下的現(xiàn)象，在故障轉(zhuǎn)移過程中的群集角色的資源狀態(tài)。當(dāng)把AlwaysOn組故障轉(zhuǎn)移到一個手動同步的節(jié)點時，會修改首選群集角色的所有者到這個節(jié)點上。此外在 AlwaysOn 資源上的可能所屬者的列表也設(shè)置為只有該節(jié)點。比如，下面的情景。當(dāng)前的AlwaysOn組的主副本活動在節(jié)點1，而主副本是同步模式并且手動故障轉(zhuǎn)移。然后我們看看群集角色和AlwaysOn資源的所有者列表：
當(dāng)我們把主節(jié)點failover到NODE3之后，再檢查：
當(dāng)AlwaysOn設(shè)置為有同步副本且自動故障轉(zhuǎn)移之后，資源列表又變得不同了。這里重新設(shè)置NODE3/4兩個為同步、自動故障轉(zhuǎn)移，然后再次查看：
注意：這些屬性都是動態(tài)管理的，所以沒有必要干預(yù)。
總結(jié)：
本節(jié)延時了AlwaysON可用性組的創(chuàng)建、配置和使用。同時測試了故障轉(zhuǎn)移的情況。這一節(jié)是本系列最重要的一節(jié)，希望能反復(fù)練習(xí)。 在翻譯和實操的過程中，感覺對讀者的實操能力提升并沒有多大的好處，最起碼對于我，所以我想在這個系列過程中插入一篇從0開始搭建整個AlwaysOn的演示文章，文章里面不打算解釋過多，主要以step by step為主。總結(jié)
以上是生活随笔為你收集整理的SQL Server AlwaysON从入门到进阶（6）——分析和部署AlwaysOn Availability Group的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Proxy—Linux服务器代理
- 下一篇： Datawhale_大数据0期