利用SQL SERVER 2005數(shù)據(jù)庫鏡像實(shí)現(xiàn)可用性分析

我們首先來看一下什么是數(shù)據(jù)鏡像：

現(xiàn)在幾乎所有的應(yīng)用系統(tǒng)都是基于數(shù)據(jù)庫的，那么數(shù)據(jù)庫的負(fù)荷是比較大的，在一天24小時中，任何時間都有可能會有數(shù)據(jù)要保存到數(shù)據(jù)庫，或是從數(shù)據(jù)庫中讀出數(shù)據(jù)。任意時刻都會有用戶連接到我們的數(shù)據(jù)庫服務(wù)器上，幾十，幾百甚至成千上萬個用戶來連接使用我們的數(shù)據(jù)庫，那么不論是計劃內(nèi)的宕機(jī)還是計劃外的故障都會造成一定的損失。給我們的用戶或是企業(yè)帶很大的損失，特別是隨著數(shù)據(jù)時代的到來，用戶對數(shù)據(jù)的使用提出了更高的要求，那么作為一個DBA，就要想怎么做才能將這個損失減少到最低，正是因?yàn)榛谶@種需求，數(shù)據(jù)庫鏡像技術(shù)出現(xiàn)了！SQL SERVER2005中首次提出了數(shù)據(jù)庫鏡像概念。特點(diǎn)：

基于軟件的高可用性解決方案 那是完全基于軟件的高可用性解決方案。不需要增加硬件成本，也就是低硬件成本

快速的故障轉(zhuǎn)移恢復(fù)， 最主要的一個亮點(diǎn)，就是快速的故障轉(zhuǎn)移恢復(fù)。3秒（對于用戶或是DBA是特別有吸引力的） 數(shù)據(jù)量大的情況一般10秒.

在這個數(shù)據(jù)庫鏡像技術(shù)中有一個數(shù)據(jù)庫服務(wù)器我們稱為主數(shù)據(jù)庫。它負(fù)責(zé)用戶的連接和數(shù)據(jù)的處理。還有一個是從服務(wù)器，確切來說，這里應(yīng)該叫鏡像服務(wù)器，上面也有一個數(shù)據(jù)庫，叫鏡像數(shù)據(jù)庫，這個數(shù)據(jù)庫用于存放我們主數(shù)據(jù)庫的一個熱備份。也就是說它雖然不連接用戶機(jī)，但是它對于主服務(wù)器上的數(shù)據(jù)更改呀，變化呀，都能做一個熱備份，也就是說如果用戶更新了主數(shù)據(jù)庫中的內(nèi)容，那么主數(shù)據(jù)庫會根據(jù)鏡像技術(shù)將更新傳送給鏡像服務(wù)器，這樣就能保證主服務(wù)器和從服務(wù)器之間的數(shù)據(jù)是一致的，那么假如說由于某種原因，我們的主服務(wù)器或是主數(shù)據(jù)庫不可用了，例如，網(wǎng)絡(luò)中斷，系統(tǒng)故障等等，那么客戶端會重新定向到鏡像服務(wù)器，那么客戶端仍然能讀取數(shù)據(jù)，寫入數(shù)據(jù)，他感覺不到主數(shù)據(jù)庫服務(wù)已經(jīng)宕機(jī)了。所以采用數(shù)據(jù)庫鏡像技術(shù)以后，對于用戶來說這個可用性就增強(qiáng)了，而且對于故障恢復(fù)時間也縮短了。那么客戶仍然可以向鏡像數(shù)據(jù)庫上寫數(shù)據(jù)。讀數(shù)據(jù)，更新相關(guān)的事務(wù)，這是我們應(yīng)用數(shù)據(jù)庫鏡像的一個過程。 想實(shí)現(xiàn)這個過程，必須要涉及到這么幾個角色：

數(shù)據(jù)庫鏡像中的服務(wù)器角色：這幾個角色剛才通過圖形介紹了一點(diǎn)，那么在2005中有三種服務(wù)器角色，分別是

主體服務(wù)器：承載主體數(shù)據(jù)庫

接受用戶連接和事務(wù)處理請求 也就是說主體服務(wù)器正常的情況下就是主體服務(wù)器來提供服務(wù)

鏡像服務(wù)器：承載鏡像數(shù)據(jù)庫

作為主體數(shù)據(jù)庫的執(zhí)備份 所謂熱備份是說，主體數(shù)據(jù)庫上的變化會立即反應(yīng)硬驅(qū)鏡像數(shù)據(jù)庫上。

僅在故障轉(zhuǎn)移后接受用戶連接，處理事務(wù)請求

見證服務(wù)器：監(jiān)視服務(wù)器狀態(tài)和連接性，實(shí)現(xiàn)自動故障轉(zhuǎn)移 也就是說見證服務(wù)器會時刻監(jiān)視兩個服務(wù)器的狀態(tài)和連接性，當(dāng)主體服務(wù)器發(fā)生宕機(jī)或者不可用以后，見證服務(wù)器會立即啟用故障轉(zhuǎn)移，將鏡像服務(wù)器切換為主體服務(wù)器。繼續(xù)為用戶提供服務(wù)器

這是數(shù)據(jù)庫鏡像中的三個服務(wù)器角色，但是要注意一下就是這三個角色不是固定下來的，是可以變化的：

主體數(shù)據(jù)庫和鏡像數(shù)據(jù)庫互為伙伴：

主體和鏡像是可以相互轉(zhuǎn)換的

故障轉(zhuǎn)移后伙伴角色發(fā)生變化

當(dāng)主體服務(wù)器正常的情況下，用戶所有的連接及數(shù)據(jù)的更新都是直接送到主體服務(wù)器的，只不過是主體服務(wù)器再將數(shù)據(jù)備份到鏡像服務(wù)器上，但是主體服務(wù)器不可用時，此時角色就發(fā)生了改變。鏡像服務(wù)器就變成了主體服務(wù)器。那么如果原來的主體服務(wù)器恢復(fù)正常了，那么怎么辦，它就會成為鏡像服務(wù)器。所以它們的角色就徹底變化了。那如果這個服務(wù)器又不可用了。那么又是一個轉(zhuǎn)換的過程。

那大家可能又要問一個問題就是這三個角色怎么知道到底哪一個可用，哪一個不可用：

各個服務(wù)器實(shí)例通過PING交換消息相互監(jiān)視。與DOS命令的PING原理差不多，但是功能比DOS下的PING要強(qiáng)大的多，DOS下的PING只是檢查網(wǎng)絡(luò)的連通性，而此處的PING即要監(jiān)視網(wǎng)絡(luò)的連通性，這是第一步，還要監(jiān)視數(shù)據(jù)庫服務(wù)器實(shí)例的運(yùn)行情況，服務(wù)器是否是正常的，還有就是這個服務(wù)器上的數(shù)據(jù)庫是否正常。

總結(jié)一下數(shù)據(jù)庫鏡像工作過程：

正常情況下，配置好數(shù)據(jù)庫鏡像以后，用戶只能連接主體數(shù)據(jù)庫，但此時鏡像數(shù)據(jù)庫是不可用的。用戶連上去也沒有用。用戶只能使用主體服務(wù)器時，主體服務(wù)器會將數(shù)據(jù)一方面寫到自己的數(shù)據(jù)庫中，另一方面通過事務(wù)日志的方式傳給鏡像服務(wù)器，寫到鏡像服務(wù)器的數(shù)據(jù)庫，此時主體服務(wù)器會進(jìn)入一個等待狀態(tài)。等待鏡像服務(wù)器的確認(rèn)，也就是當(dāng)鏡像服務(wù)器的數(shù)據(jù)成功寫入到鏡像數(shù)據(jù)庫以后會發(fā)一個消息給主體數(shù)據(jù)庫，說我現(xiàn)在已經(jīng)完成了數(shù)據(jù)的更新了也就是在鏡像服務(wù)器上執(zhí)行了一個REDO的過程。這是一個確認(rèn)。當(dāng)主體服務(wù)器收到這個確認(rèn)以后會給客戶端一個回應(yīng)，說剛才的那個數(shù)據(jù)更新的操作已經(jīng)完成了

那么為什么能實(shí)現(xiàn)一個快速恢復(fù)機(jī)制，這主要和2005中的一個機(jī)制是分不開的

但SQL 2005不是沒有必要等到回滾結(jié)束只要在REDO之后就可以使用了，至于UNDO的操作，在用戶使用的過程中你再繼續(xù)UNDO，所以當(dāng)主體服務(wù)器發(fā)生數(shù)據(jù)更新了，鏡像服務(wù)器會以最短的時候來時間更新，以至于如果主體數(shù)據(jù)發(fā)生故障了，鏡像服務(wù)器右以在最短的時間內(nèi)接替主服務(wù)器進(jìn)行工作。

下面來介紹一下數(shù)據(jù)庫鏡像中的三種操作模式：

高可用性：最常用的。

高級別保護(hù)

高性能

下面咱們分別來看一下這三種模式，當(dāng)然最主要的就是高可用性，這是使用比較廣的一個模式

高可用性模式：

服務(wù)器角色： 主體服務(wù)器 鏡像服務(wù)器 見證服務(wù)器

應(yīng)用場景：

要求高可用性的場合 如股票交易 證券交易 銀行等。

要求實(shí)現(xiàn)自動故障轉(zhuǎn)移

確保數(shù)據(jù)的完整： 要求只要是用戶提交到服務(wù)器上的數(shù)據(jù)，那怕說數(shù)據(jù)剛提交上主體服務(wù)器就發(fā)生故障了，也能保證數(shù)據(jù)不會丟失。故障轉(zhuǎn)移之后的數(shù)據(jù)是不會丟失，從而保證數(shù)據(jù)庫的完整性

高級別保護(hù)模式：

我們從名稱上也能看出來，它的重點(diǎn)在于對數(shù)據(jù)的一種保護(hù)，而不是實(shí)現(xiàn)可用性

服務(wù)器角色： 主體服務(wù)器 鏡像服務(wù)器

應(yīng)用場景：

高的數(shù)據(jù)完整性要求

不要求自動故障轉(zhuǎn)移

對服務(wù)的可用性要求較低 也就是說主體數(shù)據(jù)庫的宕機(jī)還是可以接受的，但是數(shù)據(jù)的丟失是不可以接受的，那么這種場合可以使用高級別保護(hù)模式

因?yàn)闆]有見證服務(wù)器，所以是不能進(jìn)行自動的故障轉(zhuǎn)移的。那如果主體服務(wù)器不可用，那么想實(shí)現(xiàn)故障轉(zhuǎn)移，只能是手工完成，所以對服務(wù)器的可用性要求較低

高性能模式：

服務(wù)器角色： 主體服務(wù)器 鏡像服務(wù)器

應(yīng)用場景：

主體服務(wù)器和鏡像服務(wù)器距離很遠(yuǎn)的時候 十幾公里或是完全兩個城市

通訊鏈路有明顯的延遲

對性能的要求高于數(shù)據(jù)的完整性

原理是：當(dāng)主體服務(wù)器收到用戶的操作后，將此事務(wù)傳給鏡像服務(wù)器，因此距離遠(yuǎn)所以有明顯的延遲，所以他不會等鏡像服務(wù)器的確認(rèn)，也就是說它不管這個數(shù)據(jù)到底有沒有寫到鏡像服務(wù)器，所以這種模式就在于盡快的響應(yīng)用戶的請求，也就是對用戶對性能有一個較高的要求，這個要求是高于數(shù)據(jù)的完整性。

這種模式下會存在數(shù)據(jù)的丟失，也就是說如果主體服務(wù)器宕機(jī)了，我們會把鏡像服務(wù)器作為主體服務(wù)器，但是不能保證這里面的數(shù)據(jù)就是和主體服務(wù)器上的數(shù)據(jù)是一致的，因?yàn)橛锌赡軙衼G失。

我們對幾個概念簡單的介紹一下：

事務(wù)安全性：

FULL 主體和鏡像數(shù)據(jù)庫同步傳輸?shù)哪Ｊ剑?/p>

主體在發(fā)送日志后等待鏡像的確認(rèn)

主體和鏡像的日志完全一致

OFF

主體和發(fā)送日志后不等待鏡像的確認(rèn)，繼續(xù)處理后繼的操作。

主體失敗時在鏡像上可能丟失部分?jǐn)?shù)據(jù)

仲裁：在高可用性或是高級別保護(hù)模式下需要仲裁。以決定那一個服務(wù)器是主體服務(wù)器，

仲裁的改變將導(dǎo)致故障轉(zhuǎn)移，如主體服務(wù)器發(fā)生故障了，則會發(fā)生仲裁的改變，將鏡像服務(wù)器定為主體服務(wù)器。

形成仲裁的形式一般有這么幾種：

下面我們就來看一下如何配置數(shù)據(jù)庫鏡像： 這應(yīng)該是大家感覺很興奮的，因?yàn)槁犖椅骼飮W拉的講了半天。終于不用再受罪了。其實(shí)配置很簡單的，只要注意幾個步驟就行了。

準(zhǔn)備鏡像數(shù)據(jù)庫 在鏡像服務(wù)器上準(zhǔn)備鏡像數(shù)據(jù)庫

創(chuàng)建數(shù)據(jù)庫鏡像端點(diǎn) 在各個服務(wù)器上配置鏡像端點(diǎn)

配置安全性

啟動數(shù)據(jù)庫鏡像

下面我們就具體看一下如何去做，有哪些需要注意：

這里需要提到的一點(diǎn)的就是在SQL SERVER2005剛剛發(fā)布出來的時候數(shù)據(jù)庫鏡像這個服務(wù)默認(rèn)是關(guān)閉的，也是不支持的。在剛剛發(fā)布SQL SERVER2005正式版本的時候，認(rèn)為數(shù)據(jù)庫鏡像這個技術(shù)還不成熟，有待完善。所以如果你使用的是正式版本則無法使用這個技術(shù)。

那么需要下載SP1或是以上的補(bǔ)丁。