亚洲国产av无码精品,少妇人妻系列1～100,国产精品久久久久这里只有精品

SQL數據庫高可用 - 解決方案

SQL數據庫高可用 - 是什么?

高可用性=可靠性
高可用的本質是通過技術和工具提高可靠性,盡可能長時間保持數據可用和系統運行(正常運行時間)。

實現高可用性的原則

消除單點故障
通過冗余機制實現快速恢復
實現容錯

高可用性要求的實際上是對可靠性的要求，從本質上來說，是通過技術和工具來提高可靠性，盡可能長時間保持數據的可用和系統的正常運行時間。實現高可用性的原則為排除單點故障、通過冗余實現快速恢復，并且具有容錯機制。

關于可靠性的關鍵詞

恢復

實現可靠性的最簡單的方法,從錯誤中恢復。

邏輯備份

逐行復制數據,通常將數據從二進制形式轉換為sQL語句來復制。

物理備份

從磁盤存儲層復制數據的二進制副本。

冗余

具有兩個或多個在系統中扮演相同角色的組件。

可擴展性

縮短存儲和檢索數據的時間。

容錯

發現錯誤,從事件中恢復。

MYSQL/SQL數據庫高可用解決方案

數據庫高可用性解決方案目前大致分為5種，按照高可用的級別（99.9999%為最高級）排序依次為，主從復制、具有自動故障轉移功能的主從復制、利用共享存儲、OS 或虛擬化軟件實現主備架構、MySQL Group Replication 群組復制，以及 MySQL NDB Cluster。

MySQL Replication：允許數據從一臺實例上復制到一臺或多臺其它的實例上。
MySQL Group Replication：群組復制提供更好的冗余性、自動恢復以及寫入擴展。
MySQL InnoDB Cluster：基于群組復制，提供了易于管理的 API、應用故障轉移和路由、易于配置，提供比群組復制更高級別的可用性。
MySQL NDB Cluster：容易與 MySQL InnoDB Cluster 混淆，是另外一款產品，提供更高級別的可用性和冗余性。適用于分布式計算環境，使用內存型的 NDB 存儲引擎。關于這款產品的詳細內容將不會在這里介紹。

SQL數據庫高可用 - 基本原理

經典的主從復制是 MySQL 原生的復制功能，采用異步方式，如圖片最上面顯示的原理，主服務器執行更改數據的事務后，會產生 binlog，之后 binlog 會被發送到從服務器變成 relay log，與此同時，主服務器會對應用提交返回。從服務器接收到 relay log 后，會通過一個 applier 的線程對日志里面的內容進行施放，使產生的數據更改寫入從服務器，之后產生自己的 binlog，進行提交。
采用異步的方式，在發生網絡問題和服務器損壞的情況下（從服務器未接收到日志，主服務器已經提交，并且提交后主服務器徹底損壞）會丟失數據，為了防止數據丟失，半同步復制在異步的基礎上增加了一個日志確認的環節，在從服務器接收到日志后，返回給主服務器一個應答，之后主服務器才能對應用提交返回。
作為 MySQL 目前最新的復制方式，群組復制 MGR 可以通過群組內任意服務器對數據進行更新，而不是像前面兩種有主從之分。為此群組復制增加了一個驗證步驟，通過驗證的事務才能進行提交，提交后群組內其它成員同樣對日志進行釋放，提交。

依靠什么來決定使用哪一種高可用性技術？

很多企業都需要他們的全部或部分數據高可用，比如說在線購物網站，在線商品數據庫必7*24小時在線，否則在競爭激烈的市場環境下，宕機時間就意味著流失客戶和收入當然，在一個理想的世界中，所有的關鍵數據都會時刻在線，但在現實世界中，會存在各種各樣的原因導致數據庫不可用，由于無法預估災難出現的時間和形式，需要提前采取措施來預防各種突發情況，因此SQL Server提供了多種高可用性技術，這些技術主要包括：集群、復制、鏡像、日志傳送、AlwaysOn可用性組以及其它諸如文件組備份還原、在線重建索引等單實例的高可用性技術。使用何種高可用性技術并不是隨意挑一個熟悉技術直接使用，而是要基于業務和技術綜合考慮。因為沒有一項單獨的技術可以實現所有的功能。如何根據具體的業務和預算采用這些技術，就是所謂的高可用性策略。

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

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文件）

事務日志傳送

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

常見備份方式
根據主機和備機之間同步數據的程度，備份可以分為三種情況，分別為冷備份、暖備份和熱備份。

冷備份

冷備份也就是所謂的備份，備用服務器被配置用于接受主服務器的數據，當出故障時，手動將數據還原到主數據庫，或是重新配置程序的連接字符串或權限來使得備份數據庫上線。

暖備份

暖備份也就是主服務器數據會不停的將日志傳送到備用服務器（間隔不定，可以是15分鐘，30分鐘，1分鐘等等），在這方式下，主服務器到備份服務器通常是異步更新，所以不能保證主服務器和備份服務器數據一致。此外，該方案通常不會實現自動故障監測和故障轉移。

熱備份

熱備份也就是主服務器的數據自動在備份服務器上進行同步，大多數情況下都會包含自動的故障監測和故障轉移，并且能夠保證主服務器和備份服務器的數據一致性。提示：隨著冷備份到暖備份到熱備份，成本會直線上升。

SQL數據庫高可用 - 鏡像概述

數據庫鏡像維護一個數據庫的兩個副本，這兩個副本必須駐留在不同的 SQL Server 數據庫引擎服務器實例上。通常，這些服務器實例駐留在不同位置的計算機上。啟動數據庫上的數據庫鏡像操作時，在這些服務器實例之間形成一種關系，稱為“數據庫鏡像會話”。
其中一個服務器實例使數據庫服務于客戶端（“主體服務器”），另一個服務器實例則根據鏡像會話的配置和狀態，充當熱備用或溫備用服務器（“鏡像服務器”）。同步數據庫鏡像會話時，數據庫鏡像提供熱備用服務器，可支持在已提交事務不丟失數據的情況下進行快速故障轉移。未同步會話時，鏡像服務器通常用作熱備用服務器（可能造成數據丟失）。
在“數據庫鏡像會話”中，主體服務器和鏡像服務器作為“伙伴”進行通信和協作。兩個伙伴在會話中扮演互補的角色：“主體角色”和“鏡像角色”。在任何給定的時間，都是一個伙伴扮演主體角色，另一個伙伴扮演鏡像角色。每個伙伴擁有其當前角色。擁有主體角色的伙伴稱為“主體服務器”，其數據庫副本為當前的主體數據庫。擁有鏡像角色的伙伴稱為“鏡像服務器”，其數據庫副本為當前的鏡像數據庫。如果數據庫鏡像部署在生產環境中，則主體數據庫即為“生產數據庫”。
數據庫鏡像涉及盡快將對主體數據庫執行的每項插入、更新和刪除操作“重做”到鏡像數據庫中。重做通過將活動事務日志記錄的流發送到鏡像服務器來完成，這會盡快將日志記錄按順序應用到鏡像數據庫中。與邏輯級別執行的復制不同，數據庫鏡像在物理日志記錄級別執行。從 SQL Server 2008 開始，在事務日志記錄的流發送到鏡像服務器之前，主體服務器會先將其壓縮。在所有鏡像會話中都會進行這種日志壓縮。

?數據庫鏡像的優點

數據庫鏡像是一種簡單的策略，具有下列優點：

提高數據庫的可用性

發生災難時，在具有自動故障轉移功能的高安全性模式下，自動故障轉移可快速使數據庫的備用副本聯機（而不會丟失數據）。在其他運行模式下，數據庫管理員可以選擇強制服務（可能丟失數據），以替代數據庫的備用副本。有關詳細信息，請參閱本主題后面的角色切換。

增強數據保護功能

在 SQL Server 2008 Enterprise 或更高版本上運行的數據庫鏡像伙伴會自動嘗試解決某些阻止讀取數據頁的錯誤。無法讀取頁的伙伴會向其他伙伴請求新副本。如果此請求成功，則將以新副本替換不可讀的頁，這通常會解決該錯誤。

提高生產數據庫在升級期間的可用性

為了盡量減少鏡像服務器的停機時間，您可以按順序升級承載故障轉移伙伴的 SQL Server 實例。這樣只會導致一個故障轉移的停機時間。這種形式的升級稱為“滾動升級”。數據庫鏡像實際上是個軟件解決方案，同樣提供了數據庫級別的保護，可提供幾乎是瞬時的故障轉移，以提高數據庫的可用性。數據庫鏡像可以用來維護相應生產數據庫（稱為“主體數據庫”）的單個備用數據庫（或“鏡像數據庫”）。因為鏡像數據庫一直處于還原狀態，但并不會恢復數據庫，因此無法直接訪問鏡像數據庫。但是，為了用于報表等只讀的負載，可創建鏡像數據庫的數據庫快照來間接地使用鏡像數據庫。數據庫快照為客戶端提供了快照創建時對數據庫中數據的只讀訪問。每個數據庫鏡像配置都涉及包含主體數據庫的“主體服務器”，并且還涉及包含鏡像數據庫的鏡像服務器。鏡像服務器不斷地使鏡像數據庫隨主體數據庫一起更新。數據庫鏡像在高安全性模式下以同步操作運行，或在高性能模式下以異步操作運行。在高性能模式下，事務不需要等待鏡像服務器將日志寫入磁盤便可提交，這樣可較大程度地提高性能。在高安全性模式下，已提交的事務將由伙伴雙方提交，但會延長事務滯后時間。數據庫鏡像的最簡單配置僅涉及主體服務器和鏡像服務器。在該配置中，如果主體服務器丟失，則該鏡像服務器可以用作備用服務器，但可能會造成數據丟失。高安全性模式支持具有自動故障轉移功能的備用配置高安全性模式。這種配置涉及到稱為“見證服務器”的第三方服務器實例，它能夠使鏡像服務器用作熱備份服務器。從主體數據庫至鏡像數據庫的故障轉移通常要用幾秒鐘的時間。數據庫鏡像可用于做暖備份和熱備份。

?數據庫鏡像術語和定義

自動故障轉移 (automatic failover)? ?一種過程，當主體服務器不可用時，該過程將導致鏡像服務器接管主體服務器的角色，并使其數據庫的副本聯機以作為主體數據庫。
故障轉移伙伴 (failover partners)? ? ?充當鏡像數據庫的角色切換伙伴的兩個服務器實例（主體服務器或鏡像服務器）。是指在負責將服務傳輸到鏡像數據庫（但它處于未知狀態）的主體服務器出現故障時數據庫所有者啟動的故障轉移。
高性能模式 (High-performance mode)? 數據庫鏡像會話異步運行并僅使用主體服務器和鏡像服務器。唯一的角色切換形式是強制服務（可能造成數據丟失）。

高安全性模式 (High-safety mode)

數據庫鏡像會話同步運行并可以選擇使用見證服務器、主體服務器和鏡像服務器。

手動故障轉移 (manual failover)

是指在負責將服務從主體數據庫傳輸到鏡像數據庫（處于同步狀態）的主體服務器仍在運行時數據庫所有者啟動的故障轉移。

鏡像數據庫 (mirror database)

通常與主體數據庫完全同步的數據庫副本。

鏡像服務器 (mirror server)

在數據庫鏡像配置中，鏡像數據庫所在的服務器實例。

鏡像服務器 (mirror server)

在數據庫鏡像配置中，鏡像數據庫所在的服務器實例。

主體數據庫 (principal database)

數據庫鏡像中的一種讀寫數據庫，其事務日志記錄將應用到數據庫的只讀副本（鏡像數據庫）。

主體服務器 (principal server)

在數據庫鏡像中，是指當前作為主體數據庫的數據庫所屬于的伙伴。

重做隊列 (redo queue)

收到的等待鏡像服務器磁盤的事務日志記錄。

角色 (role)

主體服務器和鏡像服務器擔任互補的主體角色和鏡像角色。也可以由第三個服務器實例來擔任見證服務器角色。

角色切換 (role switching)

鏡像接管主體角色。

發送隊列 (send queue)

在主體服務器的日志磁盤累積的未發送的事務日志記錄。

會話 (session)

是指主體服務器、鏡像服務器和見證服務器（如果存在）之間進行數據庫鏡像期間形成的關系。

鏡像會話啟動或繼續后，將累積在主體服務器上的主體數據庫日志記錄發送給鏡像服務器的過程，此過程將這些日志記錄盡快寫入磁盤，以便與主體服務器保持同步。

事務安全 (Transaction safety)

一種鏡像特定的數據庫屬性，用于確定數據庫鏡像會話是同步運行還是異步運行。有兩種安全級別：FULL 和 OFF。

見證服務器 (Witness)

僅用于高安全性模式，SQL Server 的一個可選實例，它能使鏡像服務器識別何時要啟動自動故障轉移。與這兩個故障轉移伙伴不同的是，見證服務器并不能用于數據庫。見證服務器的唯一角色是支持自動故障轉移。

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

AlwaysOn可用性組

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