久久婷婷综合色丁香五月,国内精品久久久久影院优

SQL數(shù)據(jù)庫高可用 - 解決方案

SQL數(shù)據(jù)庫高可用 - 是什么?

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

實現(xiàn)高可用性的原則

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

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

關于可靠性的關鍵詞

恢復

實現(xiàn)可靠性的最簡單的方法,從錯誤中恢復。

邏輯備份

逐行復制數(shù)據(jù),通常將數(shù)據(jù)從二進制形式轉(zhuǎn)換為sQL語句來復制。

物理備份

從磁盤存儲層復制數(shù)據(jù)的二進制副本。

冗余

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

可擴展性

縮短存儲和檢索數(shù)據(jù)的時間。

容錯

發(fā)現(xiàn)錯誤,從事件中恢復。

MYSQL/SQL數(shù)據(jù)庫高可用解決方案

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

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

SQL數(shù)據(jù)庫高可用 - 基本原理

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

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

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

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

RTO（Recovery Time Objective）也就是恢復時間目標，意味著允許多少宕機時間，通常用幾個9表示，比如說99.999%的可用性意味著每年的宕機時間不超過5分鐘、99.99%的可用性意味著每年的宕機時間不超過52.5分鐘、99.9%的可用性意味著每年的宕機時間不超過8.75小時。值得注意的是，RTO的計算方法要考慮系統(tǒng)是24*365，還是僅僅是上午6點到下午9點等。您還需要注意是否維護窗口的時間在算在宕機時間之內(nèi)，如果允許在維護窗口時間進行數(shù)據(jù)庫維護和打補丁，則更容易實現(xiàn)更高的可用性。
RPO（Recovery Point Objective）-也就是恢復點目標，意味著允許多少數(shù)據(jù)損失。通常只要做好備份，可以比較容易的實現(xiàn)零數(shù)據(jù)損失。但當災難發(fā)生時，取決于數(shù)據(jù)庫損壞的程度，從備份恢復數(shù)據(jù)所需要的時間會導致數(shù)據(jù)庫不可用，這會影響RTO的實現(xiàn)。一個早期比較著名的例子是某歐美的銀行系統(tǒng)，只考慮的RPO，系統(tǒng)里只存在了完整備份和日志備份，每3個月一次完整備份，每15分鐘一次日志備份，當災難發(fā)生時，只能夠通過完整備份和日志備份來恢復數(shù)據(jù)，因此雖然沒有數(shù)據(jù)丟失，但由于恢復數(shù)據(jù)花了整整兩天時間，造成銀行系統(tǒng)2天時間不可用，因此流失了大量客戶。另外一個相反的例子是國內(nèi)某在線視頻網(wǎng)站，使用SQL Server作為后端關系數(shù)據(jù)庫，前端使用了No-SQL，定期將No-SQL的數(shù)據(jù)導入關系數(shù)據(jù)庫作為備份，當災難發(fā)生時最多允許丟失一天的數(shù)據(jù)，但是要保證高可用性。
預算 –RTO和RPO統(tǒng)稱為SLA（服務水平協(xié)議），設計高可用性策略時，要根據(jù)業(yè)務來衡量滿足何種程度的SLA，這要取決于預算以及衡量不同SLA在故障時所造成的損失。SLA并不是越高越好，而是要基于業(yè)務需求，通常來說，在有限的預算之下很難實現(xiàn)很高的SLA，并且即使通過復雜的架構實現(xiàn)較高的SLA，復雜的架構也意味著高運維成本，因此需要在預算范圍之內(nèi)選擇合適的技術來滿足SLA。

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

SQL Server中所支持的高可用性功能與版本息息相關，企業(yè)版支持所有的高可用性功能，這些功能包括：

故障轉(zhuǎn)移集群
數(shù)據(jù)庫鏡像
事務日志傳送
數(shù)據(jù)庫快照
AlwaysOn可用性組
熱加載內(nèi)存
在線索引操作
數(shù)據(jù)庫部分在線（只還原了主文件組或主文件組和額外的NDF文件）

事務日志傳送

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

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

冷備份

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

暖備份

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

熱備份

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

SQL數(shù)據(jù)庫高可用 - 鏡像概述

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

?數(shù)據(jù)庫鏡像的優(yōu)點

數(shù)據(jù)庫鏡像是一種簡單的策略，具有下列優(yōu)點：

提高數(shù)據(jù)庫的可用性

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

增強數(shù)據(jù)保護功能

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

提高生產(chǎn)數(shù)據(jù)庫在升級期間的可用性

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

?數(shù)據(jù)庫鏡像術語和定義

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

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

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

手動故障轉(zhuǎn)移 (manual failover)

是指在負責將服務從主體數(shù)據(jù)庫傳輸?shù)界R像數(shù)據(jù)庫（處于同步狀態(tài)）的主體服務器仍在運行時數(shù)據(jù)庫所有者啟動的故障轉(zhuǎn)移。

鏡像數(shù)據(jù)庫 (mirror database)

通常與主體數(shù)據(jù)庫完全同步的數(shù)據(jù)庫副本。

鏡像服務器 (mirror server)

在數(shù)據(jù)庫鏡像配置中，鏡像數(shù)據(jù)庫所在的服務器實例。

鏡像服務器 (mirror server)

在數(shù)據(jù)庫鏡像配置中，鏡像數(shù)據(jù)庫所在的服務器實例。

主體數(shù)據(jù)庫 (principal database)

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

主體服務器 (principal server)

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

重做隊列 (redo queue)

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

角色 (role)

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

角色切換 (role switching)

鏡像接管主體角色。

發(fā)送隊列 (send queue)

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

會話 (session)

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

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

事務安全 (Transaction safety)

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

見證服務器 (Witness)

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

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

AlwaysOn可用性組

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