SQL Server 2012配置Always On可用性組

阿新 • • 發佈：2020-09-01

一、AlwaysOn簡介

AlwaysOn可用性組是SQL Server 2012中提供的全新功能，確保了應用程式資料的可用性，實現零資料丟失。AlwaysOn可用性組技術融合了資料庫群集和資料庫映象的優點，此技術的一大好處是提供非共享儲存，可以避免因為儲存的單點故障而造成的整個可用性方案失效。

AlwaysOn可用性組基於資料庫(組)級別，是將一組使用者資料庫(可以是一個或多個)劃到一個組中。每組可用性資料庫都由一個可用性副本承載。可用性副本包括一個主副本和一到四個輔助副本。主副本用於承載主資料庫，輔助副本則承載一組輔助資料庫並作為可用性組的潛在故障轉移目標。主副本使主資料庫可用於客戶端的讀寫連線，實現對資料庫的更改操作。同時在資料庫級別進行同步。主副本將每個主資料庫的事務日誌記錄傳送到每個輔助資料庫。每個輔助副本快取事務日誌記錄，然後將它們還原到相應的輔助資料庫。主資料庫與每個連線的輔助資料庫獨立進行資料同步。因此，一個輔助資料庫可以掛起或失敗而不會影響其他輔助資料庫，一個主資料庫可以掛起或失敗而不會影響其他主資料庫。

部署 AlwaysOn 可用性組需要一個 Windows Server 故障轉移群集 (WSFC) 群集。給定可用性組的每個可用性副本必須位於相同 WSFC 群集的不同節點上。部署AlwaysOn可用性組時，系統會為每個可用性組建立一個 WSFC 資源組。WSFC 群集將監視此資源組，判斷節點間的狀態，以便評估主副本的執行狀況。當發生失敗時實現故障的轉移，針對 AlwaysOn 可用性組的仲裁基於 WSFC 群集中的所有節點，而與某一給定群集節點是否承載任何可用性副本無關。

使用者可以通過建立一個可用性組偵聽器來提供到給定可用性組的主副本的客戶端連線。 “可用性組偵聽器”採用DNS名稱的方式連線給定可用性組的資源，以便將客戶端連線定向到相應的可用性副本。

對於每個可用性副本，AlwaysOn所支援的事務提交模式分為同步提交模式或非同步提交模式。在非同步提交模式下，主副本無需等待確認非同步提交輔助副本已強制寫入日誌，便可提交事務。非同步提交模式可最大限度地減少輔助資料庫上的事務滯後時間，但允許它們滯後於主資料庫，因此可能會導致某些資料丟失。此可用性模式是一種災難恢復解決方案，適合於可用性副本的分佈距離較遠的情況;所謂同步提交模式是指在提交事務之前，同步提交主副本要等待同步提交輔助副本確認它已完成強制寫入日誌。同步提交模式可確保在給定的輔助資料庫與主資料庫同步時，充分保護已提交的事務。這種保護的代價是延長事務滯後時間。此可用性模式相對於效能而言更強調高可用性和資料保護，當主副本和輔助副本距離較近時可以使用此方法，解決時時同步的問題。

當Windows群集觸發故障轉移後，故障轉移目標（原先的輔助副本）能夠接管主副本角色，對自己管理的資料庫進行恢復操作，使它們作為新的主資料庫。原先的主副本如果在故障轉移後還可用，就會成為輔助副本，它上面的資料庫就成為了輔助資料庫。

故障轉移形式是由主副本和故障轉移目標兩者的模式所共同決定的。兩個副本間要發生自動故障轉移，需要兩者都配置為同步提交模式+自動故障轉移模式。兩者中有一個配置了手動故障轉移，則自動故障轉移就不能發生。兩者間有一個配置了非同步提交模式，則它們之間就只能發生強制故障轉移。

強制故障轉移可能會丟失資料。自動故障轉移和手動故障轉移會保證資料的安全。為了防止丟失資料，自動故障轉移和手動故障轉移都要求故障轉移目標是使用同步提交模式的輔助副本且當時處於SYNCHRONIZED狀態。如果已處於SYNCHRONIZED狀態的輔助副本發出強制故障轉移命令，其行為與手動故障轉移時的行為相同。對於非同步提交模式的輔助副本，無論資料是否已經達到同步，它永遠只會處於SYNCHRONIZING狀態，於是它只能支援強制故障轉移這一種形式。

相對於資料庫映象，AlwaysOn的一個重要優勢就是可以將輔助資料庫配置成可讀模式，這極大地增強了資料庫整體的伸縮性。通過將只讀請求分流到輔助資料庫，主副本的工作負載得到了減輕，讀和寫之間的衝突可以得到緩解，輔助副本的硬體資源也能得到利用。同時，通過AlwaysOn的“只讀路由”功能，只讀操作可以動態地被轉向輔助副本。在一定程度上，可以實現對終端使用者透明。利用這個功能，SQL Server可以實現工作負荷的Scale-out（由多臺SQL Server同時響應客戶端發來的工作負載）。當客戶端連線使用Listener的名字來訪問SQL Server例項時，只讀路由功能可以將來自客戶端的只讀請求從主副本上自動重定向到可讀的輔助副本上去執行。客戶端應用程式只需要確保連線的伺服器名是Listener的名字，而無須去關心背後到底是哪個副本響應這個請求。這個功能可以自動分流一部分主副本的工作負載，使得主副本有更多的資源處理其他讀寫請求。

要讓只讀操作能“透明”地被自動轉向輔助副本，必須解決下面三個問題：

客戶端要標明自己發來的操作是“只讀”操作。這個判定是程式開發員在編寫程式的時候，通過ApplicationIntent關鍵字指定的，ApplicationIntent=ReadOnly，ApplicationIntent=ReadWrite
輔助資料庫要被配成可讀模式。

客戶端的連線，要能夠被重定向到可讀輔助副本。AlwaysOn是用“只讀路由”機制來實現的。

本文原始出處：江健龍的技術部落格http://jiangjianlong.blog.51cto.com/3735273/1791763

二、部署環境準備

1、部署環境

2、建立故障轉移群集，使用共享磁碟作為仲裁盤。如果有3個以上節點，可以不必使用仲裁盤，但是使用仲裁盤仍是保障群集良好執行的推薦方式

3、在兩個節點都獨立安裝SQL2012SP1，注意是獨立安裝，而非群集節點安裝

4、在兩個節點都啟用SQL Server Always On可用性組

5、在SQL2012-01上建立TestDB，並設定恢復模式為完整

6、為TestDB做一次完整備份

7、將儲存備份包的目錄共享出來並設定相應的許可權

三、配置Always On可用性組

1、使用嚮導建立可用性組

2、指定可用性組名稱

3、選擇要新增到可用性組中的資料庫

選要新增到可用組中的資料庫。這些資料庫將會成為一個整體一同發生故障轉移。在一個可用性組裡最多可以新增100個數據庫。在資料庫名的右側，會顯示資料庫的狀態。如果該資料庫的狀態不滿足可用組的要求，那麼就無法勾選這個資料庫。資料庫要滿足的要求包括：

需要是使用者資料庫，系統資料庫不能加入可用性組。

資料庫可以讀寫。只讀的資料庫不允許加入可用性組。

資料庫要處於多使用者模式。

資料庫沒有使用AUTO_CLOSE。

資料庫的恢復模式是完全恢復。

資料庫已經做過完整備份。

不屬於任何其他的可用性組。

資料庫上沒有配置資料庫映象。

4、指定副本

點選新增副本，把第二個節點SQL2012-02新增進來（最多可以有5個可用性副本），並指定每個可用性副本的模式：

同步提交模式：該模式決定了主副本和輔助副本之間是否要保持完全同步。最多可以有3個同步提交副本。

自動故障轉移模式：該模式決定了當主副本失敗時是否將可用性組轉移到指定的輔助副本上。最多可以將兩個可用性副本配置為自動故障轉移。

可讀輔助副本：該模式決定了該副本作為輔助副本時是否可讀。

5、配置端點

端點是AlwaysOn可用性組的重要組成部分，它的主要作用有兩個：

（1）主副本和輔助副本之間通過端點傳送日誌塊和訊息，同步資料。

（2）主副本和每個輔助副本通過端點互相傳送ping來確定彼此是否互相連通

端點的配置按預設即可。

6、指定備份首選項和優先順序

首選輔助副本：如果有任何輔助副本可用，備份都應該在輔助副本上執行。如果主副本是唯一還處於線上狀態的副本，那麼備份才會在主副本上執行。

副本備份優先順序：1表示最低優先順序，100表示最高優先順序。預設情況下，所有輔助副本都具有相同的備份優先順序，如果保持這個設定，Always On就必須使用其他因素來決定執行備份的副本。

7、建立偵聽器

只能通過SQL Server為每個可用性組建立一個偵聽器。通常情況下，每個可用性組只需要一個偵聽器。偵聽器就是一個虛擬的網路名稱，可以通過這個虛擬網路名稱訪問可用性組，而不用關心連線的是哪一個節點，它會自動將請求轉發到主節點，當主節點發生故障後，輔助節點會變為主節點，偵聽器也會自動去偵聽主節點。

建立偵聽器需要提供：

（1）IP地址。建議使用靜態IP地址

（2）網路名（DNS名）。確保該名字在網路上是唯一的。這個名字就是應用程式用來連線主副本的介面，它和任意一個副本的伺服器名都不相同。

（3）埠號。需要指派一個伺服器上未被使用的埠。這樣副本例項才能成功繫結和監聽這個埠。

8、選擇初始資料同步

其他的副本通過這個共享目錄獲得資料庫的備份並在各自的例項上進行還原。這個和日誌傳送進行初始化的步驟很像。這裡要確保每個副本例項的服務賬戶對共享目錄和本地目錄有合適的讀寫許可權。另外要注意，通過這種方式初始化，要確保主副本上存放主資料庫檔案的路徑在輔助副本上也存在。

9、驗證可用性組

10、可用性組摘要

11、完成可用性組的建立

四、可用性組建立完成後檢查

1、在故障轉移群集中確認可用性組

已建立群集資源組AlwaysOnGrp01,並承載在SQL2012-01節點上。

2、登入SQL2012-01確認是主副本

3、登入SQL2012-02確認是輔助副本

4、使用偵聽器名稱登入確認是登入到主副本

五、讀寫分流配置與測試

通過將只讀請求分流到輔助資料庫，主副本的工作負載得到了減輕，讀和寫之間的衝突可以得到緩解，輔助副本的硬體資源也能得到利用。同時，通過Always On的“只讀路由”功能，只讀操作可以動態地被轉向輔助副本。在一定程度上，可以實現對終端使用者透明。利用這個功能，SQL Server可以實現工作負荷的Scale-out（由多臺SQL Server同時響應客戶端發來的工作負載）。當客戶端連線使用偵聽器的名字來訪問SQL Server例項時，只讀路由功能可以將來自客戶端的只讀請求從主副本上自動重定向到可讀的輔助副本上去執行。客戶端應用程式只需要確保連線的伺服器名是偵聽器的名字，而無須去關心背後到底是哪個副本響應這個請求。這個功能可以自動分流一部分主副本的工作負載，使得主副本有更多的資源處理其他讀寫請求。

1、建立read指標

SQL語句如下：

ALTER AVAILABILITY GROUP [AlwaysOnGrp01]

MODIFY REPLICA ON

N'SQL2012-01' WITH

(SECONDARY_ROLE (READ_ONLY_ROUTING_URL = N'tcp://SQL2012-01.lab-sql.com:1433'))

 

ALTER AVAILABILITY GROUP [AlwaysOnGrp01]

MODIFY REPLICA ON

N'SQL2012-02' WITH

(SECONDARY_ROLE (READ_ONLY_ROUTING_URL = N'tcp://SQL2012-02.lab-sql.com:1433'))

2、建立primary、 read db ur list關係

在當前的primary上為各個primary建立對應的read only url列表（有優先順序概念），為每個可能成為primary角色的server，建立相應的只讀列表，下面的程式碼由於互為readonly server，因此優先順序都是1，SQL語句如下：

ALTER AVAILABILITY GROUP [AlwaysOnGrp01]

MODIFY REPLICA ON

N'SQL2012-02' WITH

(PRIMARY_ROLE (READ_ONLY_ROUTING_LIST=('SQL2012-01')));

 

ALTER AVAILABILITY GROUP [AlwaysOnGrp01]

MODIFY REPLICA ON

N'SQL2012-01' WITH

(PRIMARY_ROLE (READ_ONLY_ROUTING_LIST=('SQL2012-02')));

3、檢視關係與優先順序

SQL語句如下：

select ar.replica_server_name, rl.routing_priority,

 (select ar2.replica_server_name

 from sys.availability_read_only_routing_lists rl2

    join sys.availability_replicas AS ar2 ON rl2.read_only_replica_id = ar2.replica_id

where rl.replica_id=rl2.replica_id and rl.routing_priority =rl2.routing_priority

    and rl.read_only_replica_id=rl2.read_only_replica_id) as 'read_only_replica_server_name'

    from sys.availability_read_only_routing_lists rl join sys.availability_replicas AS ar ON rl.replica_id = ar.replica_id