SQL Server ->> 高可用與災難恢復(HADR)技術 -- AlwaysOn可用性組(理論篇)

由於篇幅緣由,AlwaysOn可用性組被拆成了兩部分:理論部分和實戰部分。而實戰部分又被拆成了準備工做和AlwaysOn可用性組搭建。html

三篇文章各自的連接:node

SQL Server ->> 高可用與災難恢復(HADR)技術 -- AlwaysOn(理論篇)算法

SQL Server ->> 高可用與災難恢復(HADR)技術 -- AlwaysOn(實戰篇)之創建活動目錄域、DNS服務器和Windows故障轉移羣集(準備工做)sql

SQL Server ->> 高可用與災難恢復(HADR)技術 -- AlwaysOn(實戰篇)之AlwaysOn可用性組搭建數據庫

 

 

 

前言服務器

SQL Server 2012引入了全新的HADR技術 -- AlwaysOn。AlwaysOn可謂是集SQL Server 2012以前各類HADR的優勢於一身,好比故障轉移羣集的高可用行,日誌傳送的數據副本可訪問,鏡像技術的高同步和自動頁面修復。同時它的可用性組概念又規避了故障轉移羣集必須是整個實例徹底轉移的「缺點」。在架構上的可拓展性也是其一大優點。多隻讀輔助副原本幫助減輕主副本的數據讀取負載對於某些大型應用是一大利器。以及能夠再與故障轉移羣集相結合來實現更高層次的高可用也體現了其對於大型應用的支持。網絡

 

AlwaysOn可用性組的前提條件架構

1)服務器不能是域控制器負載均衡

2)服務器OS須要是Windows Server 2008或之後的版本異步

3)服務器須要是Windows故障轉移羣集的節點

 

AlwaysOn可用行組數據庫的要求

1)只能是用戶數據庫,這點和鏡像技術是同樣的;

2)可讀寫;

3)多用戶模式;

4)徹底恢復模式;

5)作過完整備份;

6)不屬於其餘的可用性組;

 

重要特性

1)多用戶數據庫爲可用性單位

2)虛擬網絡服務器名

3)三種故障轉移模式

4)最多能夠有8個輔助服務器(SQL SERVER 2012最多4個,SQL SERVER 2014最多8個)

5)主服務器和輔助服務器數據加密和壓縮

6)自動修復某些類型的數據頁面損壞

7)輔助服務器數據只讀,分擔一部分主服務器負載

8)輔助服務器能夠執行備份和DBCC命令

9)AlwaysOn專屬Dashboard、DMV、Performance Counter和Extended Events支持

 

與其餘高可用與災難恢復(HADR)技術對比

SQL Server 2012以前的版本提供的高可用與災難恢復(HADR)技術衆多,可是難有一種是「完美」或者說能夠被當作是一種解決方案的。各自都存在一些優缺點。

集羣:優勢是能夠故障轉移;缺點是共享了同一份數據,無副本,一旦數據出問題就徹底不可訪問;自動故障轉移是整個實例級別;

日誌傳送:最老的HADR技術,依賴於事務日誌。優勢是一個數據庫能夠同時有一個或多個數據庫副本,並且仍是能夠訪問的,能夠實現讀寫分離分擔主服務器壓力,缺點是一旦災難發生,會出現短暫的數據丟失。不支持自動故障轉移。恢復時間至關長。至關於把副本備份而後還原到當前的生產數據庫,在承當數據丟失的狀況下,前提是故障是數據庫級別,不能是硬件或者實例(Windows服務)級別。

事務複製:這個不是災難恢復技術,只是做爲高可用技術的一種。依賴於事務日誌。優勢是高可用的對象能夠細化到表級別,也能夠把它當作是ETL技術的一種選擇,用於分發數據到其餘的訂閱節點是很是好的技術,對於實現讀寫分離也是一個選擇。缺點是一旦災難發生,會出現數據丟失,並且會給服務器增長負擔。和日誌傳送同樣依賴於事務日誌,註定不少缺點二者都類似。

數據庫鏡像:SQL Server 2005後的HADR技術。優勢是能夠保證不會出現任何數據丟失,也支持故障轉移;缺點是副本不可訪問,僅在故障轉移時纔可訪問,沒法讀寫分離減輕服務器壓力。

AlwaysOn:能夠說它就是對其餘高可用與災難恢復(HADR)技術的集大成者,吸收了數據庫鏡像的數據庫級別的故障轉移,日誌傳送的副本可訪問(只讀)特色,故障轉移集羣的多節點和自動故障轉移和檢測的能力。它不像故障轉移集羣必須是對整個實例級,也不像數據庫鏡像和日誌傳送只能對單個數據庫,AlwaysOn的核心思想是「可用性組」,每一個可用性組包含的是一個或若干個數據庫,而後把整個可用性組一塊兒進行故障轉移。

 

《SQL Server 2012實施與管理實戰指南》一書中總結了這5種技術的一些特色。

 

 AlwaysOn和Windows羣集的關係

AlwaysOn的故障轉移特性是基於Windows羣集實現的。由於故障偵測和轉移也具有了一些Windows羣集的特性:

1)同一可用性組的可用性副本必須處在同一Windows羣集內

2)同一可用性組的可用性副本必須運行在不一樣的Windows節點上

3)若是某個可用性副本是一個SQL羣集實例,同一SQL羣集的其餘非活躍節點上安裝的任何其餘SQL實例不能做爲它的輔助副本

4)一個數據庫只能屬於一個可用性組

 

使用虛擬網絡服務器名和Listener,由Listener來決定是否Failover

Listener決定把客戶端請求是否重定向到其餘的輔助副本上。它自己是不支持SQL Browser的,由於使用虛擬網絡服務器名自己就是使用默認實例的一種用法。既然是使用默認實例,那也就不存在命令實例和其端口號一說了。那SQL Browser也就沒用了。若是自己使用虛擬網絡服務器名,每一個副本都使用默認實例。

 

架構流程圖

可用性模式

異步提交模式:事務被提交前無需先等待某個輔助副本將事務日誌固化。這種模式下通常輔助數據庫都是出於SYNCHRONIZING狀態。這種模式通常適用於那些主副本和輔助副本物理距離遠的狀況。

同步提交模式:事務被提交前須要先等待某個輔助副本將事務日誌固化。這種模式下輔助數據庫會出於SYNCHRONIZED狀態。

 

AlwaysOn事務提交流程

 

可用性副本鏈接狀態

DISCONNECTED: 主副本和輔助副本間互相發送ping。默認超時時間爲10秒。最低爲5秒。建議10秒甚至更長,避免SQL Server過於繁忙。

 

可用性模式對事務複製的影響

事務複製的Log Reader不會去處理那些還沒有複製到輔助副本的日誌記錄。由於若是事務複製處理了這些日誌,就會形成訂閱服務器的記錄比輔助服務器的數據新鮮度要新。這時一旦發生Failover,輔助副本就會被自動切換成主副本,這樣就會出現輔助副本的數據比訂閱服務器的記錄舊。這種狀況是不容許。

 

故障轉移形式

AlwaysOn經過加載了一個名爲hadrres的DLL。由於AlwaysOn其實也是依託Windows羣集服務,因此其實也是由RHS.exe進程來加載這個DLL。從名字能夠看出是High Availibility Disaster Recovery Resource的簡稱。也就是其實這條進程是用於控制可用性組資源的上下線的。

AlwaysOn和SQL Server的羣集實際上是同樣經過調用存儲過程sp_server_dianostics來檢查羣集的狀態。調用方法存在hadrres.dll中。hadrres.dll開啓一條線程鏈接到SQL Server而且一直保持,不斷調用這個存儲過程來獲取SQL Server的狀態信息。返回結果和AlwaysOn可用性組的FailureConditionLevel配置進行對比,以決定是否切換到輔助副本上。

HealthCheckTimeout間隔爲30000毫秒。一個實例只會運行一次sp_server_dianostics,無論有多少個可用性組。多個可用性組將選擇最小的間隔設置值值除以3做爲生效的間隔。sp_server_dianostics只是檢查實例的狀態,而不是檢查數據庫的狀態。

 

故障恢復模式:自動,手動和強制

 

AlwaysOn是否觸發故障轉移是由故障恢復模式和可用性模式決定的

 

 自動故障轉移:

1)主副本和輔助副本鏈接狀態置爲DISCONNECTED而且斷開全部客戶端鏈接;

2)等待輔助副本把日誌操做前滾(redo)完畢

3)輔助副本切換爲主副本,此時若是沒有任何可用輔助副本,主副本的可用性組狀態就是NOTSYNCHRONIZED

4)原來的主副本變成可用後變成輔助副本,同步現有主副本後面生成的日誌記錄

 

手動故障轉移:

當主副本和輔助副本處於SYNCHRONIZED狀態時,能夠執行手動故障轉移。此時不會出現數據丟失。

 

強制故障轉移

當主副本中止,輔助副本進入「RESOLVING」角色。此時RESOLVING角色既不是主副本也不是輔助副本。若是執行強制故障轉移把輔助副本轉成主副本,可能出現數據丟失。並且,其餘副本在執行完強制故障轉移以後可能須要從新配置可用性組,由於強制故障轉移形式致使新的主副本不能肯定與其餘副本間的數據一致性。

 

手動故障轉移的途徑:

1)T-SQL語句

2)SSMS UI界面

3) PowerShell

 

多子網可用性組的故障轉移

客戶端應用程序使用MultiSubsetFailover來支持多子網可用性組的故障轉移,配置Listener

 

Split Brain(大腦分裂)

大腦分裂是指發生故障轉移時存在新的主副本上線和舊的主副本仍然在線存在的這種同時出現兩個主副本的狀況。爲了不這種狀況,AlwaysOn可用性組有一個叫LeaseTimeout,意思是若是主副本在LeaseTimeout以前沒有收到Windows羣集服務的消息,就會自動終止SQL Server的運行。由於其實主動權在Windows羣及服務手中。它認定故障轉移發生並轉向另外的新的主副本,從而不發生通訊消息給舊的主副本。LeaseTimeout很快就到,這樣舊的主副本就會終止本身的服務。從而避免大腦分裂。

 

只讀輔助數據庫

輔助副本上的數據庫是能夠被配置成只讀,而後經過AlwaysOn的只讀路由功能將只讀請求重定向到只讀輔助副本上,從而已經分擔主副本的工做負載。鑑於SQL Server容許最多能夠有6個輔助副本,也就是意味着咱們最多能夠有6個只讀輔助數據庫來分擔讀的壓力。固然越多的輔助副本,數據滯後的可能性就越大,由於每一個輔助副本的負載都不盡相同,與其增長多副本,倒不如把資源集中在兩個或者三個副本上。建議不要超過4個副本。把主副本和輔助副本都放置在同一局域網(同一臺交換機相連),配置主副本和輔助副本的可用性模式爲異步提交模式。雖然這樣數據滯後的發生可能性會增大,也就是數據出現延遲。這裏實際上是有兩種方案。一種是多個輔助副本,每一個副本(包括主副本和輔助副本)的硬件配置相同(參考了攜程的架構設計),並且把輔助副本的數量保持在2個內。另一種是主副本和輔助副本的硬件配置不相同,根據其角色的特徵選定硬件,這種能夠參考攜程的數據庫架構。前者的好處是能夠把可用性模式設置爲同步提交模式,讓可用性數據庫的數據延遲降至最低。這是基於相同的硬件和處在局域網高速網絡的條件考慮下作出的判斷。加上限定了儘量少的輔助副原本避免過多副本形成的數據滯後影響。理論上是能夠。不過即使如此,數據的延遲也確定仍是會出現。最重要的一點,也是缺點,就是硬件代碼過高了。容易形成硬件浪費。若是不是大型應用,並且對數據實時性的要求又很高,能夠考慮這套作法,也就是把資源都儘可能集中在兩個或者三個機器或者羣集上。第二種作法是主副本使用SAN存儲結構,加上SQL Failover羣集,多個輔助副本使用SSD存儲結構保證數據讀取和寫入的速度,可用性模式配置成異步,最後加上負載均衡硬件機器來分散數據讀取請求。能夠參考《數據庫技術與應用專場-03AlwaysOn技術在攜程核心數據庫的應用》。對於整個架構我惟一處在的疑問在於,配置成異步提交模式覺得着會出現數據延遲。而攜程的作法是經過一張表明可用性資源組時間戳的表來表明數據的新鮮度,而後應用程序在讀取輔助副本數據的時候檢查這張表以判斷是否超過數據延遲的允許程度,以決定是否把數據讀取訪問返回給主副本。若是能夠有效地控制好數據延遲的上限,那也能夠接受。由於這樣假設一旦出現N個線程排隊等待修改同一行數據的狀況,這個時候交易事務提交後到了主副本中檢查數據行的數據版本(提交表單中帶有的,來自於輔助副本上)和數據庫中的當前行是否一致,不一致則說明數據過時,這個時候事務失敗。其實也就是要結合應用程序和數據庫技術,最後須要承當起必定的代價。我是這麼看的。

 

SQL SERVER實現只讀輔助數據庫的重導向依靠的是:

1)它的「只讀路由」功能;

2)輔助數據庫配置爲只讀模式;

3)應用程序發起鏈接時指定了ApplicationIntent爲READONLY。

 

ApplicationIntent

目前支持ApplicationIntent的數據庫驅動有:SQLNCLI11 ODBC和OLEDB、.NET FRAMEWORK的SQLClient和JDBC for SQL Server 4.0

 

只讀路由

SQL Server的只讀路由功能會幫助你分流一部分的讀取請求去到輔助數據庫上。可是須要說明,在多個輔助數據庫的狀況下,到底最後面會去到哪一個輔助數據庫上是會收到路由配置和副本的狀態影響的。因此說自己SQL Server本身是沒有辦法實現負載均衡。要實現比較真實的負載均衡,你須要依靠專業的負載均衡機器來幫助實現(經過直接訪問實例名),或者經過應用程序層面編寫一套本身的算法來分攤負載。

主副本的鏈接訪問類型:ALL -- 默認,容許讀寫;READ_WRITE -- 不容許鏈接字符串帶有Application_Intent = Readonly

輔助副本的鏈接訪問類型:ALL -- 只是爲了知足那些沒法使用Application_Intent的客戶端,其實不管如何只要嘗試修改數據都會報錯;READ_ONLY -- 爲了支持只讀路由自動分流數據讀取;NONE -- 不接受任何訪問請求;

只讀路由的工做前提是Application_Intent = READONLY和使用Listener來鏈接可用性組。

 

輔助數據庫上的潛在性能問題

阻塞和死鎖

因爲輔助數據庫須要和主數據庫進行數據同步,寫入操做是幾乎可能不間斷的發生,而又由於可能同時也是一個只讀的數據庫,因此鎖的衝突、阻塞和死鎖是潛在的問題。阻塞問題在AlwaysOn是有行版本控制來解決的。全部對輔助數據庫的數據查詢都運行在快照隔離級別下。即使如此,查詢仍是會申請架構共享鎖(Sch-S),因此仍是存在和DDL語句相沖突。死鎖也是可能發生的,不過AlwaysOn的事務日誌重寫是優先級別高而不可能被選爲犧牲者。

行版本控制和臨時統計信息帶來的Tempdb的空間增加

行版本控制和臨時統計信息可能帶來的Tempdb的空間增加。須要對Tempdb的合理配置,好比Growth和Maximum Size的配置,數據文件數量的配置,文件location的選擇。

 

監控AlwaysOn可用性組的運行狀態

1)系統視圖和動態管理視圖(DMV)

實例級別的:

sys.dm_hadr_cluster

sys.dm_hadr_cluster_members

sys.dm_hadr_cluster_networks

sys.dm_hadr_instance_node_map

sys.dm_hadr_name_id_map

 

可用性組級別:

sys.availability_groups

sys.availability_groups_cluster

sys.dm_hadr_availability_groups_states

 

可用性副本級別:

sys.availability_replicas

sys.availability_read_only_routing_lists

sys.dm_hadr_availability_replica_cluster_nodes

sys.dm_hadr_availability_replica_cluster_states

sys.dm_hadr_availability_replica_states

sys.fn_hadr_backup_is_preferred_replica

 

可用性數據庫級別:

sys.availability_databases_cluster

sys.databases

sys.dm_hadr_auto_page_repair

sys.dm_hadr_database_replica_states

sys.dm_hadr_database_replica_cluster_states

 

與可用性組的Listener相關

sys.availability_group_listener_ip_addresses

sys.availability_group_listeners

sys.dm_tcp_listener_states

 

2)性能計數器

SQL Server:Availability Replica

SQL Server:Database Replica

 

3)Dashboard

 

4) AlwaysOn_health會話(Extended Events)

 

5)SQLDIAG拓展事件日誌

 

理論篇到此就結束了。接下來的實戰篇由於篇幅緣由被拆成了兩部分:1)活動目錄域、DNS服務器和Windows故障轉移羣集;2)AlwaysOn可用性組搭建;

 

參考:

《SQL Server 2012實施與管理實戰指南》

AlwaysOn Architecture Guide: Building a High Availability and Disaster Recovery Solution by Using Failover Cluster Instances and Availability Groups

SQL Server 2012 - High Availability - AlwaysOn in Real-life

Prerequisites, Restrictions, and Recommendations for AlwaysOn Availability Groups (SQL Server)

Windows Server Failover Clustering (WSFC) with SQL Server

SQL Server 2012 AlwaysOn High Availability and Disaster Recovery Design Patterns

AlwaysOn 可用性組概述 (SQL Server)

相關文章
相關標籤/搜索