| 導購 | 订阅 | 在线投稿
分享
 
 
當前位置: 王朝網路 >> mssql >> 深入了解SQL Server 2008高可用性
 

深入了解SQL Server 2008高可用性

2008-11-20 07:24:42  編輯來源:互聯網  简体版  手機版  評論  字體: ||
 
 
  基于磁盤的備份

   首先來看的是最簡單的技術——備份。在SQL Server 2008的企業版中,備份有了一個新的特性,那就是備份壓縮。那麽備份壓縮對于高可用有什麽幫助呢?

   那麽就要提到現在業界非常流行的一種備份解決方案——磁盤備份解決方案,有很多與該解決方案相近的名稱:在線備份、虛擬磁帶庫等等。這些方案其實都是基于一個思想,將數據備份到快速的在線磁盤設備上,這樣就可以利用磁盤的高速IO和高速檢索能力。不過磁盤的高昂代價往往是這種企業在這一解決方案面前駐足不前的主要原因,而現在SQL Server 2008企業版中的備份壓縮可以大幅度減少備份後的文件尺寸,因此基于磁盤的備份解決方案看起來也更加有競爭力了。

   基于磁盤的備份帶來最大的好處就是利用磁盤高速IO的能力進行快速的還原。這就可以縮短數據庫服務離線的時間,同時也可以減少數據庫備份這一維護操作對應用的影響。

   數據庫鏡像+故障轉移集群

   上面我們介紹的故障轉移集群、日志傳送亦或基于磁盤的備份都是作爲單一技術出現的,而在真實的大中型企業環境中爲了確保數據應用的持續在線,我們通常有一些組合多種高可用技術的方案。通過混合不同可用性技術,我們將可以采長補短。

   例如數據庫鏡像技術。

   雖然數據庫鏡像可以解決故障轉移集共享存儲存在單點失效威脅、依賴于特殊硬件等一系列的問題,但是數據庫鏡像最大的問題就是故障轉移路徑過短。對于大中型企業來說,僅有兩個節點的故障轉移路徑有些不足。因此通過增加一個故障轉移集群作爲數據庫鏡像的鏡像節點就可以解決了數據庫鏡像故障轉移路徑過短的問題。

   上面這種解決方案當主體服務器失效後,數據庫鏡像會將啓動鏡像節點,而由于鏡像節點是由一個故障轉移集群承擔的,因此當鏡像節點中的一個節點失效後還有一個後備節點,因此還可以有一個後備節點承擔。

   其實故障轉移集群和數據庫鏡像是各有利弊,因此這兩種技術融合在一起後的解決方案不僅僅是上面這一種,下面就給出另外一種解決方案的示意圖:

   細心的讀者可能會發現,方案二種沒有了見證節點,這意味著從主集群切換到鏡像集群需要手動完成。那麽爲什麽這種解決方案中沒有了見證節點呢?

   因爲數據庫鏡像和故障轉移集群都擁有自動故障轉移的特性,如果兩種技術的自動切換都生效的話,那麽在主體集群的活動節點失效後就會有兩個節點同時試圖生效——主體集群的後備節點和鏡像集群的活動節點,那麽結果就只有一個,數據庫鏡像會話失敗。

   遠程故障轉移集群

   對于某些跨地區甚至是跨洲的大型集團來說,站點失效這個困擾會逐漸進入IT主管和DBA的腦海中。

   不過遠程故障轉移集群就不僅僅是SQL Server一個人就能完成的了,這個方案要依賴于SQL Server,Windows Server這些基礎軟件,還要依賴于存儲設備、交換機、服務器這些硬件。

   因爲在遠程故障轉移集群中,共享儲存不再存在于一個數據中心,而是可能相距數十公裏,甚至數千公裏,因此中長距的底層存儲同步往往是這一解決方案的關鍵。對于中長距的底層存儲同步,通常分爲兩種,一種是在30公裏內的,通過單模光纖可以實現兩個數據中心存儲設備間的同步複制,而另外一種則是在30公裏之外了,而這種情況通常都是通過租用ICP的線路來實現兩地間的異步複制。

   聽上去好像很複雜,不過不用擔心,EMC這樣的廠商有非常成熟的硬件設備以及相關軟件。這就是爲什麽在SQL Server的Always On中會出現EMC這樣第三方廠商名字的原因。

   遠程故障轉移集群的替代方案

   哦,天哪!我們討論的解決方案似乎越來越貴。我可不希望這樣結束。

   其實對于遠程故障轉移集群來說,主要解決的問題是站點失效的問題,因此單純使用SQL Server的功能也可以解決這個問題。盡管沒有基于硬件的那麽高效和穩定。

   那麽怎麽構建一個相對廉價的遠程容災方案呢?我們的答案是故障轉移集群+日志傳送/複制。在不提到這兩項技術的話,他們兩個一定會有意見的。

   日志傳送依賴于日志備份以及還原來實現數據同步的,而複制呢,除了日志外多了一個快照(注意:複制中使用日志的方式與日志傳送是不一樣的)。因此我們只要確保主服務器的日志能夠以一個合理的頻率傳送給遠端的後備服務器,我們就可以提供一定程度上遠程容災能力了。

   可是在SQL Server 2005之前,複制和日志傳送都有一些小問題,日志傳送是依賴于日志備份作業、日志傳送作業和日志還原作業,因此日志傳送無法做到連續性,他的嘴短同步間隔是一分鍾,無法再短了。事務複制盡管能做連續,但是事務複制有主從之分,如果是多站點這項技術會嚴重限制後備服務器的自治能力。

   不過從SQL Server 2005開始,事務複制有了一種新的模式,叫做對等事務複制。對等事務複制平等看待參與複制的所有節點,而取消了主從之分。這就給我們的多站點數據服務規劃指出了一條新的道路。

   不過大家在這張有些誇張的圖裏面也許可以看出些端倪。通過對等事務複制,我們確實可以設計出一個非常複雜的數據複制拓撲,利用高速/低速線路,優質/常規線路,我們可以在分布于多個站點的服務器之間構建出一個複制拓撲。說上面這張圖是開玩笑,原因是通常複制拓撲不會這麽混亂,但是對等複制一定可以制成這張圖上出現的服務器數量,關鍵是要良好規劃和設計。

   算了,給張清楚點的吧。這是一個比較真實地對等複制拓撲,我們有兩個站點。站點內擁有高速的鏈接,而站點間則是相對低速的租用鏈路。A、B、C分別是三個應用的數據庫,A和C是本地性應用,因此僅在單個站點內進行了複制,保證其容災能力,而B是一個集團性的應用,爲了確保其數據的可用性,因此在站點內和站點間分別實現了複制冗余,同時站點A和站點B可以互不幹擾對數據的使用(當然這要依賴于數據庫的設計和對等複制鏈路的配置)。

   SQL Server 2008在對等複制方面也有一個小小的改進,那就是沖突檢測。在SQL Server 2005的對等事務複制中,沖突是一個非常頭疼的事情,因此才會要求非常嚴格的數據訪問隔離設計。SQL Server 2008會在發生沖突的時候暫停複制,既保證了兩個站點間的正常數據訪問,也保證了在數據沖突時不會錯誤覆蓋正確的數據版本。

   結束語

   其實SQL Server的可用性和數據應用的可用性完全是兩個層面的事情,SQL Server僅僅是數據應用中的一個組成部分,因此如何達到真正的系統可用性,還要考慮更多的問題,通訊(交換機、路由器之類)、網絡服務(DNS、DHCP之類)、操作系統、應用服務(IIS、中間件服務器),還有很多很多的問題。

   美國人遭遇了911,我們遭遇了512,除了沈重的傷痛之外也留給我們許多需要思考的問題。盡管對于很多IT來說,911和512似乎很遙遠,不過我們也討論到了IT系統需要面對的不僅僅是這些巨大的災難,還有飓風、火災、硬件故障、軟件缺陷、人爲破壞,甚至是例行維護。因此規劃和實施有效的可用性方案算是未雨綢缪,當遇到真正的突發事件時,才能避免花費成百數千倍的代價去彌補。
 
 
 
上一篇《您的SQL Server應用程序查詢正在浪費內存嗎?》
下一篇《如何使用SQL Server數據庫查詢累計值》
 
 
 
日版寵物情人插曲《Winding Road》歌詞

日版寵物情人2017的插曲,很帶節奏感,日語的,女生唱的。 最後聽見是在第8集的時候女主手割傷了,然後男主用嘴幫她吸了一下,插曲就出來了。 歌手:Def...

兄弟共妻,我成了他們夜裏的美食

老鍾家的兩個兒子很特別,就是跟其他的人不太一樣,魔一般的執著。兄弟倆都到了要結婚的年齡了,不管自家老爹怎麽磨破嘴皮子,兄弟倆說不娶就不娶,老父母爲兄弟兩操碎了心...

如何磨出破洞牛仔褲?牛仔褲怎麽剪破洞?

把牛仔褲磨出有線的破洞 1、具體工具就是磨腳石,下面墊一個硬物,然後用磨腳石一直磨一直磨,到把那塊磨薄了,用手撕開就好了。出來的洞啊很自然的。需要貓須的話調幾...

我就是掃描下圖得到了敬業福和愛國福

先來看下敬業福和愛國福 今年春節,支付寶再次推出了“五福紅包”活動,表示要“把欠大家的敬業福都還給大家”。 今天該活動正式啓動,和去年一樣,需要收集“五福”...

冰箱異味産生的原因和臭味去除的方法

有時候我們打開冰箱就會聞到一股異味,冰箱裏的這種異味是因爲一些物質發出的氣味的混合體,聞起來讓人惡心。 産生這些異味的主要原因有以下幾點。 1、很多人有這種習...

《極品家丁》1-31集大結局分集劇情介紹

簡介 《極品家丁》講述了現代白領林晚榮無意回到古代金陵,並追隨蕭二小姐化名“林三”進入蕭府,不料卻陰差陽錯上演了一出低級家丁拼搏上位的“林三升職記”。...

李溪芮《極品家丁》片尾曲《你就是我最愛的寶寶》歌詞

你就是我最愛的寶寶 - 李溪芮 (電視劇《極品家丁》片尾曲) 作詞:常馨內 作曲:常馨內 你的眉 又鬼馬的挑 你的嘴 又壞壞的笑 上一秒吵鬧 下...

烏梅的功效與作用以及烏梅的食用禁忌有哪些?

烏梅,又稱春梅,中醫認爲,烏梅味酸,性溫,無毒,具有安心、除熱、下氣、祛痰、止渴調中、殺蟲的功效,治肢體痛、肺痨病。烏梅泡水喝能治傷寒煩熱、止吐瀉,與幹姜一起制...

什麽是脂肪粒?如何消除臉部脂肪粒?

什麽是脂肪粒 在我們的臉上總會長一個個像脂肪的小顆粒,弄也弄不掉,而且顔色還是白白的。它既不是粉刺也不是其他的任何痘痘,它就是脂肪粒。 脂肪粒雖然也是由油脂...

網絡安全治理:國家安全保障的主要方向是打擊犯罪,而不是處置和懲罰受害者

來源:中國青年報 新的攻擊方法不斷湧現,黑客幾乎永遠占據網絡攻擊的上風,我們不可能通過技術手段杜絕網絡攻擊。國家安全保障的主要方向是打擊犯罪,而不是處置和懲罰...

 
 
 
基于磁盤的備份 首先來看的是最簡單的技術——備份。在SQL Server 2008的企業版中,備份有了一個新的特性,那就是備份壓縮。那麽備份壓縮對于高可用有什麽幫助呢? 那麽就要提到現在業界非常流行的一種備份解決方案——磁盤備份解決方案,有很多與該解決方案相近的名稱:在線備份、虛擬磁帶庫等等。這些方案其實都是基于一個思想,將數據備份到快速的在線磁盤設備上,這樣就可以利用磁盤的高速IO和高速檢索能力。不過磁盤的高昂代價往往是這種企業在這一解決方案面前駐足不前的主要原因,而現在SQL Server 2008企業版中的備份壓縮可以大幅度減少備份後的文件尺寸,因此基于磁盤的備份解決方案看起來也更加有競爭力了。 基于磁盤的備份帶來最大的好處就是利用磁盤高速IO的能力進行快速的還原。這就可以縮短數據庫服務離線的時間,同時也可以減少數據庫備份這一維護操作對應用的影響。 數據庫鏡像+故障轉移集群 上面我們介紹的故障轉移集群、日志傳送亦或基于磁盤的備份都是作爲單一技術出現的,而在真實的大中型企業環境中爲了確保數據應用的持續在線,我們通常有一些組合多種高可用技術的方案。通過混合不同可用性技術,我們將可以采長補短。 例如數據庫鏡像技術。 雖然數據庫鏡像可以解決故障轉移集共享存儲存在單點失效威脅、依賴于特殊硬件等一系列的問題,但是數據庫鏡像最大的問題就是故障轉移路徑過短。對于大中型企業來說,僅有兩個節點的故障轉移路徑有些不足。因此通過增加一個故障轉移集群作爲數據庫鏡像的鏡像節點就可以解決了數據庫鏡像故障轉移路徑過短的問題。 上面這種解決方案當主體服務器失效後,數據庫鏡像會將啓動鏡像節點,而由于鏡像節點是由一個故障轉移集群承擔的,因此當鏡像節點中的一個節點失效後還有一個後備節點,因此還可以有一個後備節點承擔。 其實故障轉移集群和數據庫鏡像是各有利弊,因此這兩種技術融合在一起後的解決方案不僅僅是上面這一種,下面就給出另外一種解決方案的示意圖: 細心的讀者可能會發現,方案二種沒有了見證節點,這意味著從主集群切換到鏡像集群需要手動完成。那麽爲什麽這種解決方案中沒有了見證節點呢? 因爲數據庫鏡像和故障轉移集群都擁有自動故障轉移的特性,如果兩種技術的自動切換都生效的話,那麽在主體集群的活動節點失效後就會有兩個節點同時試圖生效——主體集群的後備節點和鏡像集群的活動節點,那麽結果就只有一個,數據庫鏡像會話失敗。 遠程故障轉移集群 對于某些跨地區甚至是跨洲的大型集團來說,站點失效這個困擾會逐漸進入IT主管和DBA的腦海中。 不過遠程故障轉移集群就不僅僅是SQL Server一個人就能完成的了,這個方案要依賴于SQL Server,Windows Server這些基礎軟件,還要依賴于存儲設備、交換機、服務器這些硬件。 因爲在遠程故障轉移集群中,共享儲存不再存在于一個數據中心,而是可能相距數十公裏,甚至數千公裏,因此中長距的底層存儲同步往往是這一解決方案的關鍵。對于中長距的底層存儲同步,通常分爲兩種,一種是在30公裏內的,通過單模光纖可以實現兩個數據中心存儲設備間的同步複制,而另外一種則是在30公裏之外了,而這種情況通常都是通過租用ICP的線路來實現兩地間的異步複制。 聽上去好像很複雜,不過不用擔心,EMC這樣的廠商有非常成熟的硬件設備以及相關軟件。這就是爲什麽在SQL Server的Always On中會出現EMC這樣第三方廠商名字的原因。 遠程故障轉移集群的替代方案 哦,天哪!我們討論的解決方案似乎越來越貴。我可不希望這樣結束。 其實對于遠程故障轉移集群來說,主要解決的問題是站點失效的問題,因此單純使用SQL Server的功能也可以解決這個問題。盡管沒有基于硬件的那麽高效和穩定。 那麽怎麽構建一個相對廉價的遠程容災方案呢?我們的答案是故障轉移集群+日志傳送/複制。在不提到這兩項技術的話,他們兩個一定會有意見的。 日志傳送依賴于日志備份以及還原來實現數據同步的,而複制呢,除了日志外多了一個快照(注意:複制中使用日志的方式與日志傳送是不一樣的)。因此我們只要確保主服務器的日志能夠以一個合理的頻率傳送給遠端的後備服務器,我們就可以提供一定程度上遠程容災能力了。 可是在SQL Server 2005之前,複制和日志傳送都有一些小問題,日志傳送是依賴于日志備份作業、日志傳送作業和日志還原作業,因此日志傳送無法做到連續性,他的嘴短同步間隔是一分鍾,無法再短了。事務複制盡管能做連續,但是事務複制有主從之分,如果是多站點這項技術會嚴重限制後備服務器的自治能力。 不過從SQL Server 2005開始,事務複制有了一種新的模式,叫做對等事務複制。對等事務複制平等看待參與複制的所有節點,而取消了主從之分。這就給我們的多站點數據服務規劃指出了一條新的道路。 不過大家在這張有些誇張的圖裏面也許可以看出些端倪。通過對等事務複制,我們確實可以設計出一個非常複雜的數據複制拓撲,利用高速/低速線路,優質/常規線路,我們可以在分布于多個站點的服務器之間構建出一個複制拓撲。說上面這張圖是開玩笑,原因是通常複制拓撲不會這麽混亂,但是對等複制一定可以制成這張圖上出現的服務器數量,關鍵是要良好規劃和設計。 算了,給張清楚點的吧。這是一個比較真實地對等複制拓撲,我們有兩個站點。站點內擁有高速的鏈接,而站點間則是相對低速的租用鏈路。A、B、C分別是三個應用的數據庫,A和C是本地性應用,因此僅在單個站點內進行了複制,保證其容災能力,而B是一個集團性的應用,爲了確保其數據的可用性,因此在站點內和站點間分別實現了複制冗余,同時站點A和站點B可以互不幹擾對數據的使用(當然這要依賴于數據庫的設計和對等複制鏈路的配置)。 SQL Server 2008在對等複制方面也有一個小小的改進,那就是沖突檢測。在SQL Server 2005的對等事務複制中,沖突是一個非常頭疼的事情,因此才會要求非常嚴格的數據訪問隔離設計。SQL Server 2008會在發生沖突的時候暫停複制,既保證了兩個站點間的正常數據訪問,也保證了在數據沖突時不會錯誤覆蓋正確的數據版本。 結束語 其實SQL Server的可用性和數據應用的可用性完全是兩個層面的事情,SQL Server僅僅是數據應用中的一個組成部分,因此如何達到真正的系統可用性,還要考慮更多的問題,通訊(交換機、路由器之類)、網絡服務(DNS、DHCP之類)、操作系統、應用服務(IIS、中間件服務器),還有很多很多的問題。 美國人遭遇了911,我們遭遇了512,除了沈重的傷痛之外也留給我們許多需要思考的問題。盡管對于很多IT來說,911和512似乎很遙遠,不過我們也討論到了IT系統需要面對的不僅僅是這些巨大的災難,還有飓風、火災、硬件故障、軟件缺陷、人爲破壞,甚至是例行維護。因此規劃和實施有效的可用性方案算是未雨綢缪,當遇到真正的突發事件時,才能避免花費成百數千倍的代價去彌補。
󰈣󰈤
 
 
 
  免責聲明:本文僅代表作者個人觀點,與王朝網路無關。王朝網路登載此文出於傳遞更多信息之目的,並不意味著贊同其觀點或證實其描述,其原創性以及文中陳述文字和內容未經本站證實,對本文以及其中全部或者部分內容、文字的真實性、完整性、及時性本站不作任何保證或承諾,請讀者僅作參考,並請自行核實相關內容。
 
 
可愛女生泡泡生活(4)
可愛女生泡泡生活(3)
可愛女生泡泡生活(2)
盛服濃妝_模特周敬(5)
康莊大道
家鄉的老城門
石室教堂
我心中的香格裏拉—泸沽湖
 
>>返回首頁<<
 
 熱帖排行
 
 
 
 
© 2005- 王朝網路 版權所有