|
因?yàn)槠?，AlwaysOn可用性組被拆成了兩部分：理論部分和實(shí)戰(zhàn)部分。而實(shí)戰(zhàn)部分又被拆成了準(zhǔn)備工作和AlwaysOn可用性組搭建。 三篇文章各自的鏈接： SQL Server ->> 高可用與災(zāi)難恢復(fù)（HADR）技術(shù) -- AlwaysOn（理論篇） SQL Server ->> 高可用與災(zāi)難恢復(fù)（HADR）技術(shù) -- AlwaysOn（實(shí)戰(zhàn)篇）之AlwaysOn可用性組搭建
前言 SQL Server 2012引入了全新的HADR技術(shù) -- AlwaysOn。AlwaysOn可謂是集SQL Server 2012之前各種HADR的優(yōu)點(diǎn)于一身，比如故障轉(zhuǎn)移群集的高可用行，日志傳送的數(shù)據(jù)副本可訪問，鏡像技術(shù)的高同步和自動(dòng)頁面修復(fù)。同時(shí)它的可用性組概念又規(guī)避了故障轉(zhuǎn)移群集必須是整個(gè)實(shí)例完全轉(zhuǎn)移的“缺點(diǎn)”。在架構(gòu)上的可拓展性也是其一大優(yōu)勢(shì)。多只讀輔助副本來幫助減輕主副本的數(shù)據(jù)讀取負(fù)載對(duì)于某些大型應(yīng)用是一大利器。以及可以再與故障轉(zhuǎn)移群集相結(jié)合來實(shí)現(xiàn)更高層次的高可用也體現(xiàn)了其對(duì)于大型應(yīng)用的支持。
AlwaysOn可用性組的前提條件 1）服務(wù)器不能是域控制器 2）服務(wù)器OS需要是Windows Server 2008或以后的版本 3）服務(wù)器需要是Windows故障轉(zhuǎn)移群集的節(jié)點(diǎn)
AlwaysOn可用行組數(shù)據(jù)庫的要求 1）只能是用戶數(shù)據(jù)庫，這點(diǎn)和鏡像技術(shù)是一樣的； 2）可讀寫； 3）多用戶模式； 4）完全恢復(fù)模式； 5）做過完整備份； 6）不屬于其他的可用性組；
重要特性 1）多用戶數(shù)據(jù)庫為可用性單位 2）虛擬網(wǎng)絡(luò)服務(wù)器名 3）三種故障轉(zhuǎn)移模式 4）最多可以有8個(gè)輔助服務(wù)器（SQL SERVER 2012最多4個(gè)，SQL SERVER 2014最多8個(gè)） 5）主服務(wù)器和輔助服務(wù)器數(shù)據(jù)加密和壓縮 6）自動(dòng)修復(fù)某些類型的數(shù)據(jù)頁面損壞 7）輔助服務(wù)器數(shù)據(jù)只讀，分擔(dān)一部分主服務(wù)器負(fù)載 8）輔助服務(wù)器可以執(zhí)行備份和DBCC命令 9）AlwaysOn專屬Dashboard、DMV、Performance Counter和Extended Events支持
與其他高可用與災(zāi)難恢復(fù)（HADR）技術(shù)對(duì)比 SQL Server 2012之前的版本提供的高可用與災(zāi)難恢復(fù)（HADR）技術(shù)眾多，但是難有一種是“完美”或者說可以被看成是一種解決方案的。各自都存在一些優(yōu)缺點(diǎn)。 集群：優(yōu)點(diǎn)是可以故障轉(zhuǎn)移；缺點(diǎn)是共享了同一份數(shù)據(jù)，無副本，一旦數(shù)據(jù)出問題就完全不可訪問；自動(dòng)故障轉(zhuǎn)移是整個(gè)實(shí)例級(jí)別； 日志傳送：最老的HADR技術(shù)，依賴于事務(wù)日志。優(yōu)點(diǎn)是一個(gè)數(shù)據(jù)庫可以同時(shí)有一個(gè)或多個(gè)數(shù)據(jù)庫副本，而且還是可以訪問的，可以實(shí)現(xiàn)讀寫分離分擔(dān)主服務(wù)器壓力，缺點(diǎn)是一旦災(zāi)難發(fā)生，會(huì)出現(xiàn)短暫的數(shù)據(jù)丟失。不支持自動(dòng)故障轉(zhuǎn)移。恢復(fù)時(shí)間相當(dāng)長(zhǎng)。相當(dāng)于把副本備份然后還原到當(dāng)前的生產(chǎn)數(shù)據(jù)庫，在承當(dāng)數(shù)據(jù)丟失的情況下，前提是故障是數(shù)據(jù)庫級(jí)別，不能是硬件或者實(shí)例（Windows服務(wù)）級(jí)別。 事務(wù)復(fù)制：這個(gè)不是災(zāi)難恢復(fù)技術(shù)，只是作為高可用技術(shù)的一種。依賴于事務(wù)日志。優(yōu)點(diǎn)是高可用的對(duì)象可以細(xì)化到表級(jí)別，也可以把它看成是ETL技術(shù)的一種選擇，用于分發(fā)數(shù)據(jù)到其他的訂閱節(jié)點(diǎn)是非常好的技術(shù)，對(duì)于實(shí)現(xiàn)讀寫分離也是一個(gè)選擇。缺點(diǎn)是一旦災(zāi)難發(fā)生，會(huì)出現(xiàn)數(shù)據(jù)丟失，而且會(huì)給服務(wù)器增加負(fù)擔(dān)。和日志傳送一樣依賴于事務(wù)日志，注定很多缺點(diǎn)兩者都相似。 數(shù)據(jù)庫鏡像：SQL Server 2005后的HADR技術(shù)。優(yōu)點(diǎn)是可以保證不會(huì)出現(xiàn)任何數(shù)據(jù)丟失，也支持故障轉(zhuǎn)移；缺點(diǎn)是副本不可訪問，僅在故障轉(zhuǎn)移時(shí)才可訪問，無法讀寫分離減輕服務(wù)器壓力。 AlwaysOn：可以說它就是對(duì)其他高可用與災(zāi)難恢復(fù)（HADR）技術(shù)的集大成者，吸取了數(shù)據(jù)庫鏡像的數(shù)據(jù)庫級(jí)別的故障轉(zhuǎn)移，日志傳送的副本可訪問（只讀）特點(diǎn)，故障轉(zhuǎn)移集群的多節(jié)點(diǎn)和自動(dòng)故障轉(zhuǎn)移和檢測(cè)的能力。它不像故障轉(zhuǎn)移集群必須是對(duì)整個(gè)實(shí)例級(jí)，也不像數(shù)據(jù)庫鏡像和日志傳送只能對(duì)單個(gè)數(shù)據(jù)庫，AlwaysOn的核心思想是“可用性組”，每個(gè)可用性組包含的是一個(gè)或若干個(gè)數(shù)據(jù)庫，然后把整個(gè)可用性組一起進(jìn)行故障轉(zhuǎn)移。
《SQL Server 2012實(shí)施與管理實(shí)戰(zhàn)指南》一書中總結(jié)了這5種技術(shù)的一些特點(diǎn)。
AlwaysOn和Windows群集的關(guān)系 AlwaysOn的故障轉(zhuǎn)移特性是基于Windows群集實(shí)現(xiàn)的。因?yàn)楣收蟼蓽y(cè)和轉(zhuǎn)移也具備了一些Windows群集的特性： 1）同一可用性組的可用性副本必須處在同一Windows群集內(nèi) 2）同一可用性組的可用性副本必須運(yùn)行在不同的Windows節(jié)點(diǎn)上 3）如果某個(gè)可用性副本是一個(gè)SQL群集實(shí)例，同一SQL群集的其他非活躍節(jié)點(diǎn)上安裝的任何其他SQL實(shí)例不能作為它的輔助副本 4）一個(gè)數(shù)據(jù)庫只能屬于一個(gè)可用性組
使用虛擬網(wǎng)絡(luò)服務(wù)器名和Listener，由Listener來決定是否Failover Listener決定把客戶端請(qǐng)求是否重定向到其他的輔助副本上。它本身是不支持SQL Browser的，因?yàn)槭褂锰摂M網(wǎng)絡(luò)服務(wù)器名本身就是使用默認(rèn)實(shí)例的一種用法。既然是使用默認(rèn)實(shí)例，那也就不存在命令實(shí)例和其端口號(hào)一說了。那SQL Browser也就沒用了。如果本身使用虛擬網(wǎng)絡(luò)服務(wù)器名，每個(gè)副本都使用默認(rèn)實(shí)例。
架構(gòu)流程圖
可用性模式 異步提交模式：事務(wù)被提交前無需先等待某個(gè)輔助副本將事務(wù)日志固化。這種模式下一般輔助數(shù)據(jù)庫都是出于SYNCHRONIZING狀態(tài)。這種模式一般適用于那些主副本和輔助副本物理距離遠(yuǎn)的情況。 同步提交模式：事務(wù)被提交前需要先等待某個(gè)輔助副本將事務(wù)日志固化。這種模式下輔助數(shù)據(jù)庫會(huì)出于SYNCHRONIZED狀態(tài)。
AlwaysOn事務(wù)提交流程
可用性副本連接狀態(tài) DISCONNECTED: 主副本和輔助副本間互相發(fā)送ping。默認(rèn)超時(shí)時(shí)間為10秒。最低為5秒。建議10秒甚至更長(zhǎng)，避免SQL Server過于繁忙。
可用性模式對(duì)事務(wù)復(fù)制的影響 事務(wù)復(fù)制的Log Reader不會(huì)去處理那些尚未復(fù)制到輔助副本的日志記錄。因?yàn)槿绻聞?wù)復(fù)制處理了這些日志，就會(huì)造成訂閱服務(wù)器的記錄比輔助服務(wù)器的數(shù)據(jù)新鮮度要新。這時(shí)一旦發(fā)生Failover，輔助副本就會(huì)被自動(dòng)切換成主副本，這樣就會(huì)出現(xiàn)輔助副本的數(shù)據(jù)比訂閱服務(wù)器的記錄舊。這種情況是不允許。
故障轉(zhuǎn)移形式 AlwaysOn通過加載了一個(gè)名為hadrres的DLL。因?yàn)锳lwaysOn其實(shí)也是依托Windows群集服務(wù)，所以其實(shí)也是由RHS.exe進(jìn)程來加載這個(gè)DLL。從名字可以看出是High Availibility Disaster Recovery Resource的簡(jiǎn)稱。也就是其實(shí)這條進(jìn)程是用于控制可用性組資源的上下線的。 AlwaysOn和SQL Server的群集其實(shí)是一樣通過調(diào)用存儲(chǔ)過程sp_server_dianostics來檢查群集的狀態(tài)。調(diào)用方法存在hadrres.dll中。hadrres.dll開啟一條線程連接到SQL Server并且一直保持，不斷調(diào)用這個(gè)存儲(chǔ)過程來獲取SQL Server的狀態(tài)信息。返回結(jié)果和AlwaysOn可用性組的FailureConditionLevel配置進(jìn)行對(duì)比，以決定是否切換到輔助副本上。 HealthCheckTimeout間隔為30000毫秒。一個(gè)實(shí)例只會(huì)運(yùn)行一次sp_server_dianostics，不管有多少個(gè)可用性組。多個(gè)可用性組將選擇最小的間隔設(shè)置值值除以3作為生效的間隔。sp_server_dianostics只是檢查實(shí)例的狀態(tài)，而不是檢查數(shù)據(jù)庫的狀態(tài)。
故障恢復(fù)模式：自動(dòng)，手動(dòng)和強(qiáng)制
AlwaysOn是否觸發(fā)故障轉(zhuǎn)移是由故障恢復(fù)模式和可用性模式?jīng)Q定的
自動(dòng)故障轉(zhuǎn)移： 1）主副本和輔助副本連接狀態(tài)置為DISCONNECTED并且斷開所有客戶端連接； 2）等待輔助副本把日志操作前滾（redo）完畢 3）輔助副本切換為主副本，此時(shí)如果沒有任何可用輔助副本，主副本的可用性組狀態(tài)就是NOTSYNCHRONIZED 4）原來的主副本變成可用后變成輔助副本，同步現(xiàn)有主副本后面生成的日志記錄
手動(dòng)故障轉(zhuǎn)移： 當(dāng)主副本和輔助副本處于SYNCHRONIZED狀態(tài)時(shí)，可以執(zhí)行手動(dòng)故障轉(zhuǎn)移。此時(shí)不會(huì)出現(xiàn)數(shù)據(jù)丟失。
強(qiáng)制故障轉(zhuǎn)移 當(dāng)主副本停止，輔助副本進(jìn)入“RESOLVING”角色。此時(shí)RESOLVING角色既不是主副本也不是輔助副本。如果執(zhí)行強(qiáng)制故障轉(zhuǎn)移把輔助副本轉(zhuǎn)成主副本，可能出現(xiàn)數(shù)據(jù)丟失。而且，其他副本在執(zhí)行完強(qiáng)制故障轉(zhuǎn)移之后可能需要重新配置可用性組，因?yàn)閺?qiáng)制故障轉(zhuǎn)移形式導(dǎo)致新的主副本不能確定與其他副本間的數(shù)據(jù)一致性。
手動(dòng)故障轉(zhuǎn)移的途徑： 1）T-SQL語句 2）SSMS UI界面 3) PowerShell
多子網(wǎng)可用性組的故障轉(zhuǎn)移 客戶端應(yīng)用程序使用MultiSubsetFailover來支持多子網(wǎng)可用性組的故障轉(zhuǎn)移，配置Listener
Split Brain（大腦分裂） 大腦分裂是指發(fā)生故障轉(zhuǎn)移時(shí)存在新的主副本上線和舊的主副本仍然在線存在的這種同時(shí)出現(xiàn)兩個(gè)主副本的情況。為了避免這種情況，AlwaysOn可用性組有一個(gè)叫LeaseTimeout，意思是如果主副本在LeaseTimeout之前沒有收到Windows群集服務(wù)的消息，就會(huì)自動(dòng)終止SQL Server的運(yùn)行。因?yàn)槠鋵?shí)主動(dòng)權(quán)在Windows群及服務(wù)手中。它認(rèn)定故障轉(zhuǎn)移發(fā)生并轉(zhuǎn)向另外的新的主副本，從而不發(fā)生通信消息給舊的主副本。LeaseTimeout很快就到，這樣舊的主副本就會(huì)終止自己的服務(wù)。從而避免大腦分裂。
只讀輔助數(shù)據(jù)庫 輔助副本上的數(shù)據(jù)庫是可以被配置成只讀，然后通過AlwaysOn的只讀路由功能將只讀請(qǐng)求重定向到只讀輔助副本上，從而已經(jīng)分擔(dān)主副本的工作負(fù)載。鑒于SQL Server允許最多可以有6個(gè)輔助副本，也就是意味著我們最多可以有6個(gè)只讀輔助數(shù)據(jù)庫來分擔(dān)讀的壓力。當(dāng)然越多的輔助副本，數(shù)據(jù)滯后的可能性就越大，因?yàn)槊總€(gè)輔助副本的負(fù)載都不盡相同，與其增加多副本，倒不如把資源集中在兩個(gè)或者三個(gè)副本上。建議不要超過4個(gè)副本。把主副本和輔助副本都放置在同一局域網(wǎng)（同一臺(tái)交換機(jī)相連），配置主副本和輔助副本的可用性模式為異步提交模式。雖然這樣數(shù)據(jù)滯后的發(fā)生可能性會(huì)增大，也就是數(shù)據(jù)出現(xiàn)延遲。這里其實(shí)是有兩種方案。一種是多個(gè)輔助副本，每個(gè)副本（包括主副本和輔助副本）的硬件配置相同（參考了攜程的架構(gòu)設(shè)計(jì)），而且把輔助副本的數(shù)量保持在2個(gè)內(nèi)。另外一種是主副本和輔助副本的硬件配置不相同，根據(jù)其角色的特征選定硬件，這種可以參考攜程的數(shù)據(jù)庫架構(gòu)。前者的好處是可以把可用性模式設(shè)置為同步提交模式，讓可用性數(shù)據(jù)庫的數(shù)據(jù)延遲降至最低。這是基于相同的硬件和處在局域網(wǎng)高速網(wǎng)絡(luò)的條件考慮下做出的判斷。加上限定了盡可能少的輔助副本來避免過多副本造成的數(shù)據(jù)滯后影響。理論上是可以。不過即便如此，數(shù)據(jù)的延遲也肯定還是會(huì)出現(xiàn)。最重要的一點(diǎn)，也是缺點(diǎn)，就是硬件代碼太高了。容易造成硬件浪費(fèi)。如果不是大型應(yīng)用，而且對(duì)數(shù)據(jù)實(shí)時(shí)性的要求又很高，可以考慮這套做法，也就是把資源都盡量集中在兩個(gè)或者三個(gè)機(jī)器或者群集上。第二種做法是主副本使用SAN存儲(chǔ)結(jié)構(gòu)，加上SQL Failover群集，多個(gè)輔助副本使用SSD存儲(chǔ)結(jié)構(gòu)保證數(shù)據(jù)讀取和寫入的速度，可用性模式配置成異步，最后加上負(fù)載均衡硬件機(jī)器來分散數(shù)據(jù)讀取請(qǐng)求?？梢詤⒖肌?a target="_blank">數(shù)據(jù)庫技術(shù)與應(yīng)用專場(chǎng)-03AlwaysOn技術(shù)在攜程核心數(shù)據(jù)庫的應(yīng)用》。對(duì)于整個(gè)架構(gòu)我唯一處在的疑問在于，配置成異步提交模式以為著會(huì)出現(xiàn)數(shù)據(jù)延遲。而攜程的做法是通過一張代表可用性資源組時(shí)間戳的表來代表數(shù)據(jù)的新鮮度，然后應(yīng)用程序在讀取輔助副本數(shù)據(jù)的時(shí)候檢查這張表以判斷是否超過數(shù)據(jù)延遲的容許程度，以決定是否把數(shù)據(jù)讀取訪問返回給主副本。如果可以有效地控制好數(shù)據(jù)延遲的上限，那也可以接受。因?yàn)檫@樣假設(shè)一旦出現(xiàn)N個(gè)線程排隊(duì)等待修改同一行數(shù)據(jù)的情況，這個(gè)時(shí)候交易事務(wù)提交后到了主副本中檢查數(shù)據(jù)行的數(shù)據(jù)版本（提交表單中帶有的，來自于輔助副本上）和數(shù)據(jù)庫中的當(dāng)前行是否一致，不一致則說明數(shù)據(jù)過期，這個(gè)時(shí)候事務(wù)失敗。其實(shí)也就是要結(jié)合應(yīng)用程序和數(shù)據(jù)庫技術(shù)，最后需要承當(dāng)起一定的代價(jià)。我是這么看的。
SQL SERVER實(shí)現(xiàn)只讀輔助數(shù)據(jù)庫的重導(dǎo)向依靠的是： 1）它的“只讀路由”功能； 2）輔助數(shù)據(jù)庫配置為只讀模式； 3）應(yīng)用程序發(fā)起連接時(shí)指定了ApplicationIntent為READONLY。
ApplicationIntent 目前支持ApplicationIntent的數(shù)據(jù)庫驅(qū)動(dòng)有：SQLNCLI11 ODBC和OLEDB、.NET FRAMEWORK的SQLClient和JDBC for SQL Server 4.0
只讀路由 SQL Server的只讀路由功能會(huì)幫助你分流一部分的讀取請(qǐng)求去到輔助數(shù)據(jù)庫上。但是需要說明，在多個(gè)輔助數(shù)據(jù)庫的情況下，到底最后面會(huì)去到哪個(gè)輔助數(shù)據(jù)庫上是會(huì)收到路由配置和副本的狀態(tài)影響的。所以說本身SQL Server自己是沒有辦法實(shí)現(xiàn)負(fù)載均衡。要實(shí)現(xiàn)比較真實(shí)的負(fù)載均衡，你需要依靠專業(yè)的負(fù)載均衡機(jī)器來幫助實(shí)現(xiàn)（通過直接訪問實(shí)例名），或者通過應(yīng)用程序?qū)用婢帉懸惶鬃约旱乃惴▉矸謹(jǐn)傌?fù)載。 主副本的連接訪問類型：ALL -- 默認(rèn)，允許讀寫；READ_WRITE -- 不允許連接字符串帶有Application_Intent = Readonly 輔助副本的連接訪問類型：ALL -- 只是為了滿足那些無法使用Application_Intent的客戶端，其實(shí)無論如何只要嘗試修改數(shù)據(jù)都會(huì)報(bào)錯(cuò)；READ_ONLY -- 為了支持只讀路由自動(dòng)分流數(shù)據(jù)讀取；NONE -- 不接受任何訪問請(qǐng)求； 只讀路由的工作前提是Application_Intent = READONLY和使用Listener來連接可用性組。
輔助數(shù)據(jù)庫上的潛在性能問題 阻塞和死鎖 由于輔助數(shù)據(jù)庫需要和主數(shù)據(jù)庫進(jìn)行數(shù)據(jù)同步，寫入操作是幾乎可能不間斷的發(fā)生，而又因?yàn)榭赡芡瑫r(shí)也是一個(gè)只讀的數(shù)據(jù)庫，所以鎖的沖突、阻塞和死鎖是潛在的問題。阻塞問題在AlwaysOn是有行版本控制來解決的。所有對(duì)輔助數(shù)據(jù)庫的數(shù)據(jù)查詢都運(yùn)行在快照隔離級(jí)別下。即便如此，查詢還是會(huì)申請(qǐng)架構(gòu)共享鎖（Sch-S），所以還是存在和DDL語句相沖突。死鎖也是可能發(fā)生的，不過AlwaysOn的事務(wù)日志重寫是優(yōu)先級(jí)別高而不可能被選為犧牲者。 行版本控制和臨時(shí)統(tǒng)計(jì)信息帶來的Tempdb的空間增長(zhǎng) 行版本控制和臨時(shí)統(tǒng)計(jì)信息可能帶來的Tempdb的空間增長(zhǎng)。需要對(duì)Tempdb的合理配置，比如Growth和Maximum Size的配置，數(shù)據(jù)文件數(shù)量的配置，文件location的選擇。
監(jiān)控AlwaysOn可用性組的運(yùn)行狀態(tài) 1）系統(tǒng)視圖和動(dòng)態(tài)管理視圖（DMV） 實(shí)例級(jí)別的： 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
可用性組級(jí)別： sys.availability_groups sys.availability_groups_cluster sys.dm_hadr_availability_groups_states
可用性副本級(jí)別： 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
可用性數(shù)據(jù)庫級(jí)別： 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相關(guān) sys.availability_group_listener_ip_addresses sys.availability_group_listeners sys.dm_tcp_listener_states
2）性能計(jì)數(shù)器 SQL Server:Availability Replica SQL Server:Database Replica
3）Dashboard
4) AlwaysOn_health會(huì)話（Extended Events）
5）SQLDIAG拓展事件日志
理論篇到此就結(jié)束了。接下來的實(shí)戰(zhàn)篇因?yàn)槠虮徊鸪闪藘刹糠郑?）活動(dòng)目錄域、DNS服務(wù)器和Windows故障轉(zhuǎn)移群集；2）AlwaysOn可用性組搭建；
參考： 《SQL Server 2012實(shí)施與管理實(shí)戰(zhàn)指南》 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
|
|
|
