SQL 數據庫高可用

自從SQL Server 2000以來,微軟已經陸續提供了多種高可用性技術來減少宕機時間和增加對業務數據的?;?,而隨著SQL Server 200、,SQL Server 2008 R2、SQL Server 2012、SQL 2014、SQL 2016的不斷發布,SQL Server中已經存在了滿足不同場景的多種高可用性技術。

sol_jc_sql1.jpg
依靠什么來決定使用哪一種高可用性技術?

很多企業都需要他們的全部或部分數據高可用,比如說在線購物網站,在線商品數據庫必7*24小時在線,否則在競爭激烈的市場環境下,宕機時間就意味著流失客戶和收入。

 

當然,在一個理想的世界中,所有的關鍵數據都會時刻在線,但在現實世界中,會存在各種各樣的原因導致數據庫不可用,由于無法預估災難出現的時間和形式,需要提前采取措施來預防各種突發情況,因此SQL Server提供了多種高可用性技術,這些技術主要包括:集群、復制、鏡像、日志傳送、AlwaysOn可用性組以及其它諸如文件組備份還原、在線重建索引等單實例的高可用性技術。使用何種高可用性技術并不是隨意挑一個熟悉技術直接使用,而是要基于業務和技術綜合考慮。因為沒有一項單獨的技術可以實現所有的功能。如何根據具體的業務和預算采用這些技術,就是所謂的高可用性策略。

 
sol_jc_sql2.jpg
在設計高可用性策略時應該首先考慮下述因素:

• RTO(Recovery Time Objective)-也就是恢復時間目標,意味著允許多少宕機時間,通常用幾個9表示,比如說99.999%的可用性意味著每年的宕機時間不超過5分鐘、99.99%的可用性意味著每年的宕機時間不超過52.5分鐘、99.9%的可用性意味著每年的宕機時間不超過8.75小時。值得注意的是,RTO的計算方法要考慮系統是24*365,還是僅僅是上午6點到下午9點等。您還需要注意是否維護窗口的時間在算在宕機時間之內,如果允許在維護窗口時間進行數據庫維護和打補丁,則更容易實現更高的可用性。

 

• RPO(Recovery Point Objective)-也就是恢復點目標,意味著允許多少數據損失。通常只要做好備份,可以比較容易的實現零數據損失。但當災難發生時,取決于數據庫損壞的程度,從備份恢復數據所需要的時間會導致數據庫不可用,這會影響RTO的實現。一個早期比較著名的例子是某歐美的銀行系統,只考慮的RPO,系統里只存在了完整備份和日志備份,每3個月一次完整備份,每15分鐘一次日志備份,當災難發生時,只能夠通過完整備份和日志備份來恢復數據,因此雖然沒有數據丟失,但由于恢復數據花了整整兩天時間,造成銀行系統2天時間不可用,因此流失了大量客戶。另外一個相反的例子是國內某在線視頻網站,使用SQL Server作為后端關系數據庫,前端使用了No-SQL,定期將No-SQL的數據導入關系數據庫作為備份,當災難發生時最多允許丟失一天的數據,但是要保證高可用性。

 

預算 –RTO和RPO統稱為SLA(服務水平協議),設計高可用性策略時,要根據業務來衡量滿足何種程度的SLA,這要取決于預算以及衡量不同SLA在故障時所造成的損失。SLA并不是越高越好,而是要基于業務需求,通常來說,在有限的預算之下很難實現很高的SLA,并且即使通過復雜的架構實現較高的SLA,復雜的架構也意味著高運維成本,因此需要在預算范圍之內選擇合適的技術來滿足SLA。

 
SQL Server中所支持的高可用特性

SQL Server中所支持的高可用性功能與版本息息相關,企業版支持所有的高可用性功能,這些功能包括:

• 故障轉移集群

• 數據庫鏡像

• 事務日志傳送

• 數據庫快照

• AlwaysOn可用性組

• 熱加載內存

• 在線索引操作

• 數據庫部分在線(只還原了主文件組或主文件組和額外的NDF文件)

 
故障轉移集群

故障轉移集群為整個SQL Server實例提供高可用性支持,這意味著在集群上某個節點的SQL Server實例發生了硬件錯誤、操作系統錯誤等會故障轉移到該集群上的其它節點。通過多個服務器(節點)共享一個或多個磁盤來實現高可用性,故障轉移集群在網絡中出現的方式就像單臺計算機一樣,但是具有高可用特性。值得注意的是,由于故障轉移集群是基于共享磁盤,因此會存在磁盤單點故障,因此需要在磁盤層面部署SAN復制等額外的?;ご朧?。常見的故障轉移集群是雙節點的故障轉移集群,包括主主節點和主從節點。

事務日志傳送

事務日志傳送提供了數據庫級別的高可用性?;?。日志傳送可用來維護相應生產數據庫(稱為“主數據庫”)的一個或多個備用數據庫(稱為“輔助數據庫”)。發生故障轉移之前,必須通過手動應用全部未還原的日志備份來完全更新輔助數據庫。日志傳送具有支持多個備用數據庫的靈活性。如果需要多個備用數據庫,可以單獨使用日志傳送或將其作為數據庫鏡像的補充。當這些解決方案一起使用時,當前數據庫鏡像配置的主體數據庫同時也是當前日志傳送配置的主數據庫。

事務日志傳送可用于做冷備份和暖備份的方式。

數據庫鏡像

數據庫鏡像實際上是個軟件解決方案,同樣提供了數據庫級別的?;?,可提供幾乎是瞬時的故障轉移,以提高數據庫的可用性。數據庫鏡像可以用來維護相應生產數據庫(稱為“主體數據庫”)的單個備用數據庫(或“鏡像數據庫”)。

 

因為鏡像數據庫一直處于還原狀態,但并不會恢復數據庫,因此無法直接訪問鏡像數據庫。但是,為了用于報表等只讀的負載,可創建鏡像數據庫的數據庫快照來間接地使用鏡像數據庫。數據庫快照為客戶端提供了快照創建時對數據庫中數據的只讀訪問。每個數據庫鏡像配置都涉及包含主體數據庫的“主體服務器”,并且還涉及包含鏡像數據庫的鏡像服務器。鏡像服務器不斷地使鏡像數據庫隨主體數據庫一起更新。

 

數據庫鏡像在高安全性模式下以同步操作運行,或在高性能模式下以異步操作運行。在高性能模式下,事務不需要等待鏡像服務器將日志寫入磁盤便可提交,這樣可較大程度地提高性能。在高安全性模式下,已提交的事務將由伙伴雙方提交,但會延長事務滯后時間。數據庫鏡像的最簡單配置僅涉及主體服務器和鏡像服務器。在該配置中,如果主體服務器丟失,則該鏡像服務器可以用作備用服務器,但可能會造成數據丟失。高安全性模式支持具有自動故障轉移功能的備用配置高安全性模式。這種配置涉及到稱為“見證服務器”的第三方服務器實例,它能夠使鏡像服務器用作熱備份服務器。從主體數據庫至鏡像數據庫的故障轉移通常要用幾秒鐘的時間。

 

數據庫鏡像可用于做暖備份和熱備份。

復制

復制嚴格來說并不算是一個為高可用性設計的功能,但的確可以被應用于高可用性。復制提供了數據庫對象級別的?;?。復制使用的是發布-訂閱模式,即由主服務器(稱為發布服務器)向一個或多個輔助服務器或訂閱服務器發布數據。復制可在這些服務器間提供實時的可用性和可伸縮性。它支持篩選,以便為訂閱服務器提供數據子集,同時還支持分區更新。訂閱服務器處于聯機狀態,并且可用于報表或其他功能,而無需進行查詢恢復。SQL Server 提供四種復制類型:快照復制、事務復制、對等復制以及合并復制。

AlwaysOn可用性組

AlwaysOn可用性組是SQL Server 2012推出的新功能。同樣提供了數據庫級別的?;?。它取數據庫鏡像和故障轉移集群之長,使得業務上有關聯的數據庫作為一個可用性組共同故障轉移,該功能還拓展了數據庫鏡像只能1對1的限制,使得1個主副本可以對應最多4個輔助副本(在SQL Server 2014中,該限制被拓展到8個),其中2個輔助副本可以被作為熱備份和主副本實時同步,而另外兩個異步輔助副本可以作為暖備份。此外,輔助副本還可以被配置為只讀,并可用于承擔備份的負載。

 

sol_jc_sql3.jpg

 

正因為如此,數據庫鏡像在SQL Server 2012中被標記為“過時”。

 

具體何種版本支持哪些高可用特性,請參閱://msdn.microsoft.com/zh-cn/library/cc645993.apx

 
您有任何想法和需求,請致電:

400-635-8089

相關解決方案

Related Solution

IT外包
>
400-635-8089