我們首先來看一下什么是數(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，就要想怎么做才能將這個損失減少到最低，正是因為基于這種需求，數(shù)據(jù)庫鏡像技術(shù)出現(xiàn)了！SQL SERVER2005中首次提出了數(shù)據(jù)庫鏡像概念。特點：
基于軟件的高可用性解決方案 那是完全基于軟件的高可用性解決方案。不需要增加硬件成本，也就是低硬件成本
快速的故障轉(zhuǎn)移恢復(fù)， 最主要的一個亮點，就是快速的故障轉(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ù)庫鏡像的一個過程。 想實現(xiàn)這個過程，必須要涉及到這么幾個角色：
數(shù)據(jù)庫鏡像中的服務(wù)器角色：這幾個角色剛才通過圖形介紹了一點，那么在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)和連接性，實現(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ù)器實例通過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ù)器實例的運行情況，服務(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)完成了
那么為什么能實現(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)用場景：
要求高可用性的場合 如股票交易 證券交易 銀行等。
要求實現(xiàn)自動故障轉(zhuǎn)移
確保數(shù)據(jù)的完整： 要求只要是用戶提交到服務(wù)器上的數(shù)據(jù)，那怕說數(shù)據(jù)剛提交上主體服務(wù)器就發(fā)生故障了，也能保證數(shù)據(jù)不會丟失。故障轉(zhuǎn)移之后的數(shù)據(jù)是不會丟失，從而保證數(shù)據(jù)庫的完整性
高級別保護(hù)模式：
我們從名稱上也能看出來，它的重點在于對數(shù)據(jù)的一種保護(hù)，而不是實現(xiàn)可用性
服務(wù)器角色： 主體服務(wù)器 鏡像服務(wù)器
應(yīng)用場景：
高的數(shù)據(jù)完整性要求
不要求自動故障轉(zhuǎn)移
對服務(wù)的可用性要求較低 也就是說主體數(shù)據(jù)庫的宕機(jī)還是可以接受的，但是數(shù)據(jù)的丟失是不可以接受的，那么這種場合可以使用高級別保護(hù)模式
因為沒有見證服務(wù)器，所以是不能進(jìn)行自動的故障轉(zhuǎn)移的。那如果主體服務(wù)器不可用，那么想實現(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ù)是一致的，因為有可能會有丟失。
我們對幾個概念簡單的介紹一下：
事務(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)該是大家感覺很興奮的，因為聽我西里嘩拉的講了半天。終于不用再受罪了。其實配置很簡單的，只要注意幾個步驟就行了。
準(zhǔn)備鏡像數(shù)據(jù)庫 在鏡像服務(wù)器上準(zhǔn)備鏡像數(shù)據(jù)庫
創(chuàng)建數(shù)據(jù)庫鏡像端點 在各個服務(wù)器上配置鏡像端點
配置安全性
啟動數(shù)據(jù)庫鏡像
下面我們就具體看一下如何去做，有哪些需要注意：
這里需要提到的一點的就是在SQL SERVER2005剛剛發(fā)布出來的時候數(shù)據(jù)庫鏡像這個服務(wù)默認(rèn)是關(guān)閉的，也是不支持的。在剛剛發(fā)布SQL SERVER2005正式版本的時候，認(rèn)為數(shù)據(jù)庫鏡像這個技術(shù)還不成熟，有待完善。所以如果你使用的是正式版本則無法使用這個技術(shù)。
那么需要下載SP1或是以上的補(bǔ)丁。
|
· 版本號
|
sql server 2005 版本
|
|
9.00.1399
|
sql server 2005（初始版本）
|
|
9.00.2047
|
sql server 2005 SP1
|
|
9.00.3042
|
sql server 2005 SP2
|
我們這里直接打SP2補(bǔ)?。郝?/p>
準(zhǔn)備數(shù)據(jù)庫：
條件 很重要：
主體數(shù)據(jù)庫必須是完全恢復(fù)模式
創(chuàng)建鏡像數(shù)據(jù)庫
在主體數(shù)據(jù)庫上做一個完全備份，在鏡像服務(wù)器上使用NORECOVER選項恢復(fù)主體數(shù)據(jù)庫。
繼續(xù)恢復(fù)后續(xù)日志備份（NORECOVER） NORECOVER 很重要
配置數(shù)據(jù)庫鏡像端點 （ENDPOINT）
數(shù)據(jù)庫鏡像端點實現(xiàn)鏡像會話的通訊，也就是各個服務(wù)器的入口點，有點類似于端口號。但不是。也就是說你創(chuàng)建了這個端點之后，各個服務(wù)器之間就可以使用TCP協(xié)議進(jìn)行實例間的通訊。每個鏡像端點上都在一個唯一的TCP端口號上偵聽，一般大家都使用5022號端口。
創(chuàng)建數(shù)據(jù)庫鏡像端點：
需要在每個實例上創(chuàng)建
只有管理員組的成員才能權(quán)限。
設(shè)置端點角色 即有的是伙伴端點，有的是見證端點，所以必須要指定。
激活端點 默認(rèn)是不能使用的，所以要激活。
下面我們看一下使用T-SQL 語句創(chuàng)建端點
CREATE ENDPOINT DBMIRRORING
AS TCP（LISTENER_PORT=5022）當(dāng)然也可以使用其他端口，只要沒有被使用
FOR DATABASE_MIRRORING(ROLE=PARTNER,ENCRYPTION=SUPPORTED) GO
-- 創(chuàng)建的是一個數(shù)據(jù)庫鏡像端點，角色是伙伴，通訊過程是通過加密的。
ALTER ENDPOINT DBMIRRORING STATE=STARTED GO --激活
此時這個端點就開始偵聽了。
創(chuàng)建見證服務(wù)器的端點：創(chuàng)建的時候激活端點。
CREATE ENDPOINT DBMIRRORING
STATE=STARTED AS TCP（LISTENER_PORT=5022）
For DATABASE_MIRRORING (ROLE=WITNESS,ENCRYPTION=SUPPORTED)
配置安全性：
數(shù)據(jù)庫鏡像中的實例之間必須可信 都使用WINDOWS 身份驗證或是基于證書的身份驗證（非信任域），為了簡單為例，我們使用WINDOWS身份驗證。
賦予服務(wù)帳戶對端點的連接權(quán)限。
在這里我們都使用相同的用戶名口令
下面我們創(chuàng)建完端點后就要啟動數(shù)據(jù)庫鏡像，注意順序很重要
指定鏡像數(shù)據(jù)庫的伙伴 在鏡像服務(wù)器上操作
指定主體數(shù)據(jù)庫伙伴 在主體服務(wù)器上操作
指定見證服務(wù)器 在見證服務(wù)器上操作
指定事務(wù)安全選項 FULL 還是 OFF
對應(yīng)語句分別是：
ALTER DATABASE NOTHWIND SET PARTNER=N'TCP：/SERVER1H:5022'
–-在SERVER2（鏡像）上執(zhí)行
ALTER DATABASE NOTHWIND SET PARTNER=N'TCP:/SERVER2:5022'
--在SERVER1（主體）上執(zhí)行
ALTER DATABASE NOTHWIND SET WITNESS=N'TCP:/SERVER3:5022'
--在SERVER1（主體）上執(zhí)行
ALTER DATABASE NOTHWIND SET SAFETY FULL;
--在SERVER1（主體）上執(zhí)行 高可用性
當(dāng)然也可以使用SMSS
那么完成之后怎么來查看數(shù)據(jù)庫鏡像是否完成，可以通過以下兩種方法：
SMSS 數(shù)據(jù)庫屬性---鏡像狀態(tài)
T-SQL
SELECT * FROM SYS.DATABASE——MIRRORING
SELECT * FROM SYS.DATABASE——MIRRORING——WITNESS
下面我們具體看一下配置高可用性數(shù)據(jù)庫鏡像
我們使用T-SQL 可以很明顯的看到配置的過程。
下面我來介紹一下我們所使用的環(huán)境：
SERVER1為主體服務(wù)器
SERVER2為鏡像服務(wù)器
SERVER3 為見證服務(wù)器
首先我們要
準(zhǔn)備數(shù)據(jù)庫：一個是備份主體數(shù)據(jù)庫，一個是在鏡像服務(wù)器上恢復(fù)。
所以
在SERVE1上：
BACKUP DATABASE NORTHWIND TO DISK='C:\NW.BAK'
在 SERVER2上：
RESTORE DATABASE NORTHWIND FROM DISK='C:\NW.BAK' WITH NORECOVERY
創(chuàng)建數(shù)據(jù)庫端點：
1． 在SERVER1上創(chuàng)建數(shù)據(jù)庫鏡像端點，用于伙伴通訊
Create endpoint dbmirrep as tcp (listener_port=5022)
For database_mirroring (role=partner,encryption=supported );
Alter endpoint dbmirrep state=started
通過圖形界面可以查看到
2． 在SERVER2上創(chuàng)建數(shù)據(jù)庫端點，也是用于伙伴通訊
Create endpoint dbmirrep as tcp (listener_port=5022)
For database_mirroring (role=partner,encryption=supported)
Alter endpoint dbmirrep state=started
3． 在SERVER3上創(chuàng)建鏡像端點，用于見證通訊
CREATE ENDPOINT DBMIRREP AS TCP （LISTENER_PORT=5022）
FOR DATABASE_MIRRORING (role=witness,encryption=supported)
ALTER ENDPOINT DBMIRREP STATE=STARTED
4． 檢查端點配置
SELECT * FROM SYS.DATABASE_MIRRORING_ENDPOINTS
也可以通過圖形界面查看
配置數(shù)據(jù)庫鏡像安全性：也就是指定哪些用戶可以使用這個端點?？隙ㄊ枪芾韱T，一般用戶不讓他訪問。
分別執(zhí)行:
Grant connect on endpoint::"dbmirrep" to "server1\dufei"
Grant connect on endpoint::"dbmirrep" to "server2\dufei"
Grant connect on endpoint::"dbmirrep" to "server3\dufei"
最后一個就是啟動數(shù)據(jù)庫鏡像。注意：順序 首先要從鏡像服務(wù)上配置
在SERVER2上，指定伙伴端點：
ALTER DATABASE ITET SET PARTNER='TCP://SERVER1:5022'
在SERVER1上，指定伙伴端點：
ALTER DATABASE itet SET PARTNER='TCP://SERVER2:5022' –查看數(shù)據(jù)庫
--到此為止，就是咱們前面所介紹的高級別保護(hù)模式。可以實現(xiàn)數(shù)據(jù)完整性，但是不能實現(xiàn)高可用性。所以還要繼續(xù)，也就是說到這里為止，不要見證服務(wù)器也可以，但是不能實現(xiàn)故障的自動轉(zhuǎn)移：
在 SERVER1上，指定見證服務(wù)器端點：
Alter database ITET set wiTness=N'TCP://SERVER3:5022'
設(shè)置數(shù)據(jù)庫鏡像事務(wù)安全級別：
ALTER DATABASE ITET SET SAFETY FULL
實驗結(jié)束,但一定要注意細(xì)節(jié)
最后看一下數(shù)據(jù)庫鏡像角色切換：也就是如何實現(xiàn)故障轉(zhuǎn)移
自動故障轉(zhuǎn)移：
只針對高可用性模式
SAFETY=FULL
測試：禁用主服務(wù)器的網(wǎng)卡，查看庫狀態(tài)，再啟用再查看
我們到這里已經(jīng)知道了如何實現(xiàn)數(shù)據(jù)庫鏡像，那么用戶如何來使用：客戶端都是連接到主體服務(wù)器上進(jìn)行工作的。那么如果主體服務(wù)器不可用了，那么就會造成用戶連接的失敗，它怎么知道去自動連接鏡像服務(wù)器，這里一般使用ADO技術(shù)，如ASP.NET 或是微軟所提借的連接工具。
我們這里借助WINDOWS 的集群功能：來進(jìn)行測試：
SERVER1與SERVER2配置成WINDOWS集群：
實驗到此結(jié)束!
本文出自 “杜飛” 博客
您可能感興趣的文章:- 監(jiān)視SQLServer數(shù)據(jù)庫鏡像[圖文]
- SQL數(shù)據(jù)庫與oracle數(shù)據(jù)庫鏡像有什么不同對比
- MySQL 數(shù)據(jù)庫雙向鏡像、循環(huán)鏡像(復(fù)制)
- mssql2005數(shù)據(jù)庫鏡像搭建教程
- SQL Server誤區(qū)30日談 第10天 數(shù)據(jù)庫鏡像在故障發(fā)生后 馬上就能發(fā)現(xiàn)
- SQL Server 2008 R2數(shù)據(jù)庫鏡像部署圖文教程
- SQL Server 2008 數(shù)據(jù)庫鏡像部署實例之一 數(shù)據(jù)庫準(zhǔn)備
- SQL Server 2008 數(shù)據(jù)庫鏡像部署實例之二 配置鏡像，實施手動故障轉(zhuǎn)移
- SQL Server 2008 數(shù)據(jù)庫鏡像部署實例之三 配置見證服務(wù)器
- SQL Server 2005 鏡像構(gòu)建手冊(sql2005數(shù)據(jù)庫同步鏡像方案)
- 簡述SQL Server 2005數(shù)據(jù)庫鏡像相關(guān)知識
