利用SQL SERVER 2005數據庫鏡像實現可用性

咱們首先來看一下什麼是數據鏡像：

如今幾乎全部的應用系統都是基於數據庫的，那麼數據庫的負荷是比較大的，在一天24小時中，任什麼時候間都有可能會有數據要保存到數據庫，或是從數據庫中讀出數據。任意時刻都會有用戶鏈接到咱們的數據庫服務器上，幾十，幾百甚至成千上萬個用戶來鏈接使用咱們的數據庫，那麼不管是計劃內的宕機仍是計劃外的故障都會形成必定的損失。給咱們的用戶或是企業帶很大的損失，特別是隨着數據時代的到來，用戶對數據的使用提出了更高的要求，那麼做爲一個DBA，就要想怎麼作才能將這個損失減小到最低，正是由於基於這種需求，數據庫鏡像技術出現了！SQL SERVER2005中首次提出了數據庫鏡像概念。特色：

基於軟件的高可用性解決方案  那是徹底基於軟件的高可用性解決方案。不須要增長硬件成本，也就是低硬件成本

快速的故障轉移恢復， 最主要的一個亮點，就是快速的故障轉移恢復。3秒（對於用戶或是DBA是特別有吸引力的） 數據量大的狀況通常10秒.

在這個數據庫鏡像技術中有一個數據庫服務器咱們稱爲主數據庫。它負責用戶的鏈接和數據的處理。還有一個是從服務器，確切來講，這裏應該叫鏡像服務器，上面也有一個數據庫，叫鏡像數據庫，這個數據庫用於存放咱們主數據庫的一個熱備份。也就是說它雖然不鏈接用戶機，可是它對於主服務器上的數據更改呀，變化呀，都能作一個熱備份，也就是說若是用戶更新了主數據庫中的內容，那麼主數據庫會根據鏡像技術將更新傳送給鏡像服務器，這樣就能保證主服務器和從服務器之間的數據是一致的，那麼假如說因爲某種緣由，咱們的主服務器或是主數據庫不可用了，例如，網絡中斷，系統故障等等，那麼客戶端會從新定向到鏡像服務器，那麼客戶端仍然能讀取數據，寫入數據，他感受不到主數據庫服務已經宕機了。因此採用數據庫鏡像技術之後，對於用戶來講這個可用性就加強了，並且對於故障恢復時間也縮短了。那麼客戶仍然能夠向鏡像數據庫上寫數據。讀數據，更新相關的事務，這是咱們應用數據庫鏡像的一個過程。  想實現這個過程，必需要涉及到這麼幾個角色：

數據庫鏡像中的服務器角色：這幾個角色剛纔經過圖形介紹了一點，那麼在2005中有三種服務器角色，分別是

主體服務器：承載主體數據庫

            接受用戶鏈接和事務處理請求          也就是說主體服務器正常的狀況下就是主體服務器來提供服務

鏡像服務器：承載鏡像數據庫

            做爲主體數據庫的執備份     所謂熱備份是說，主體數據庫上的變化會當即反應硬驅鏡像數據庫上。

            僅在故障轉移後接受用戶鏈接，處理事務請求

見證服務器：監視服務器狀態和鏈接性，實現自動故障轉移 也就是說見證服務器會時刻監視兩個服務器的狀態和鏈接性，當主體服務器發生宕機或者不可用之後，見證服務器會當即啓用故障轉移，將鏡像服務器切換爲主體服務器。繼續爲用戶提供服務器

 

這是數據庫鏡像中的三個服務器角色，可是要注意一下就是這三個角色不是固定下來的，是能夠變化的：

主體數據庫和鏡像數據庫互爲夥伴：

主體和鏡像是能夠相互轉換的

故障轉移後夥伴角色發生變化

 

當主體服務器正常的狀況下，用戶全部的鏈接及數據的更新都是直接送到主體服務器的，只不過是主體服務器再將數據備份到鏡像服務器上，可是主體服務器不可用時，此時角色就發生了改變。鏡像服務器就變成了主體服務器。那麼若是原來的主體服務器恢復正常了，那麼怎麼辦，它就會成爲鏡像服務器。因此它們的角色就完全變化了。那若是這個服務器又不可用了。那麼又是一個轉換的過程。

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

各個服務器實例經過PING交換消息相互監視。與DOS命令的PING原理差很少，可是功能比DOS下的PING要強大的多，DOS下的PING只是檢查網絡的連通性，而此處的PING即要監視網絡的連通性，這是第一步，還要監視數據庫服務器實例的運行狀況，服務器是不是正常的，還有就是這個服務器上的數據庫是否正常。  

總結一下數據庫鏡像工做過程：

正常狀況下，配置好數據庫鏡像之後，用戶只能鏈接主體數據庫，但此時鏡像數據庫是不可用的。用戶連上去也沒有用。用戶只能使用主體服務器時，主體服務器會將數據一方面寫到本身的數據庫中，另外一方面經過事務日誌的方式傳給鏡像服務器，寫到鏡像服務器的數據庫，此時主體服務器會進入一個等待狀態。等待鏡像服務器的確認，也就是當鏡像服務器的數據成功寫入到鏡像數據庫之後會發一個消息給主體數據庫，說我如今已經完成了數據的更新了也就是在鏡像服務器上執行了一個REDO的過程。這是一個確認。當主體服務器收到這個確認之後會給客戶端一個迴應，說剛纔的那個數據更新的操做已經完成了

 

那麼爲何能實現一個快速恢復機制，這主要和2005中的一個機制是分不開的

 

但SQL 2005不是沒有必要等到回滾結束只要在REDO以後就可使用了，至於UNDO的操做，在用戶使用的過程當中你再繼續UNDO，因此當主體服務器發生數據更新了，鏡像服務器會以最短的時候來時間更新，以致於若是主體數據發生故障了，鏡像服務器右以在最短的時間內接替主服務器進行工做。

下面來介紹一下數據庫鏡像中的三種操做模式：

高可用性：最經常使用的。

高級別保護

高性能

下面我們分別來看一下這三種模式，固然最主要的就是高可用性，這是使用比較廣的一個模式

高可用性模式：

服務器角色： 主體服務器   鏡像服務器  見證服務器       

應用場景：

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

要求實現自動故障轉移

確保數據的完整：  要求只要是用戶提交到服務器上的數據，那怕說數據剛提交上主體服務器就發生故障了，也能保證數據不會丟失。故障轉移以後的數據是不會丟失，從而保證數據庫的完整性

 

高級別保護模式：

咱們從名稱上也能看出來，它的重點在於對數據的一種保護，而不是實現可用性

服務器角色： 主體服務器     鏡像服務器 

應用場景：

高的數據完整性要求

不要求自動故障轉移

對服務的可用性要求較低   也就是說主體數據庫的宕機仍是能夠接受的，可是數據的丟失是不能夠接受的，那麼這種場合可使用高級別保護模式

由於沒有見證服務器，因此是不能進行自動的故障轉移的。那若是主體服務器不可用，那麼想實現故障轉移，只能是手工完成，因此對服務器的可用性要求較低

 

高性能模式：

服務器角色：  主體服務器   鏡像服務器

應用場景：

主體服務器和鏡像服務器距離很遠的時候  十幾千米或是徹底兩個城市

通信鏈路有明顯的延遲

對性能的要求高於數據的完整性

原理是：當主體服務器收到用戶的操做後，將此事務傳給鏡像服務器，所以距離遠因此有明顯的延遲，因此他不會等鏡像服務器的確認，也就是說它無論這個數據到底有沒有寫到鏡像服務器，因此這種模式就在於儘快的響應用戶的請求，也就是對用戶對性能有一個較高的要求，這個要求是高於數據的完整性。

這種模式下會存在數據的丟失，也就是說若是主體服務器宕機了，咱們會把鏡像服務器做爲主體服務器，可是不能保證這裏面的數據就是和主體服務器上的數據是一致的，由於有可能會有丟失。

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

事務安全性：

FULL 主體和鏡像數據庫同步傳輸的模式，

           主體在發送日誌後等待鏡像的確認

           主體和鏡像的日誌徹底一致

 

OFF

            主體和發送日誌後不等待鏡像的確認，繼續處理後繼的操做。

            主體失敗時在鏡像上可能丟失部分數據

 

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

     仲裁的改變將致使故障轉移，如主體服務器發生故障了，則會發生仲裁的改變，將鏡像服務器定爲主體服務器。

 

造成仲裁的形式通常有這麼幾種：

 

下面咱們就來看一下如何配置數據庫鏡像： 這應該是你們感受很興奮的，由於聽我西里譁拉的講了半天。終於不用再受罪了。其實配置很簡單的，只要注意幾個步驟就好了。

準備鏡像數據庫   在鏡像服務器上準備鏡像數據庫

建立數據庫鏡像端點  在各個服務器上配置鏡像端點

配置安全性

啓動數據庫鏡像

 

下面咱們就具體看一下如何去作，有哪些須要注意：

這裏須要提到的一點的就是在SQL SERVER2005剛剛發佈出來的時候數據庫鏡像這個服務默認是關閉的，也是不支持的。在剛剛發佈SQL SERVER2005正式版本的時候，認爲數據庫鏡像這個技術還不成熟，有待完善。因此若是你使用的是正式版本則沒法使用這個技術。

那麼須要下載SP1或是以上的補丁。

·   版本號	sql server 2005 版本
9.00.1399	sql server 2005 （初始版本）
9.00.2047	sql server 2005 SP1
9.00.3042	sql server 2005 SP2

咱們這裏直接打SP2補丁：略

 

準備數據庫：

條件 很重要：

主體數據庫必須是徹底恢復模式

建立鏡像數據庫

在主體數據庫上作一個徹底備份，在鏡像服務器上使用NORECOVER選項恢復主體數據庫。

繼續恢復後續日誌備份（NORECOVER） NORECOVER 很重要

 

配置數據庫鏡像端點 （ENDPOINT）

數據庫鏡像端點實現鏡像會話的通信，也就是各個服務器的入口點，有點相似於端口號。但不是。也就是說你建立了這個端點以後，各個服務器之間就可使用TCP協議進行實例間的通信。每一個鏡像端點上都在一個惟一的TCP端口號上偵聽，通常你們都使用5022號端口。

 

建立數據庫鏡像端點：

須要在每一個實例上建立

只有管理員組的成員才能權限。

設置端點角色 即有的是夥伴端點，有的是見證端點，因此必需要指定。

激活端點   默認是不能使用的，因此要激活。

 

下面咱們看一下使用T-SQL 語句建立端點

 

CREATE ENDPOINT  DBMIRRORING

AS TCP（LISTENER_PORT=5022）固然也可使用其餘端口，只要沒有被使用

FOR DATABASE_MIRRORING(ROLE=PARTNER,ENCRYPTION=SUPPORTED) GO

-- 建立的是一個數據庫鏡像端點，角色是夥伴，通信過程是經過加密的。

 

ALTER ENDPOINT DBMIRRORING STATE=STARTED   GO  --激活

此時這個端點就開始偵聽了。

 

建立見證服務器的端點：建立的時候激活端點。

CREATE ENDPOINT DBMIRRORING

STATE=STARTED  AS TCP（LISTENER_PORT=5022）

For DATABASE_MIRRORING (ROLE=WITNESS,ENCRYPTION=SUPPORTED)

 

 

配置安全性：

數據庫鏡像中的實例之間必須可信 都使用WINDOWS 身份驗證或是基於證書的身份驗證（非信任域），爲了簡單爲例，咱們使用WINDOWS身份驗證。

賦予服務賬戶對端點的鏈接權限。

在這裏咱們都使用相同的用戶名口令

 

下面咱們建立完端點後就要啓動數據庫鏡像，注意順序很重要

指定鏡像數據庫的夥伴    在鏡像服務器上操做

指定主體數據庫夥伴      在主體服務器上操做

指定見證服務器          在見證服務器上操做

指定事務安全選項   FULL 仍是 OFF

 

對應語句分別是：

ALTER DATABASE NOTHWIND  SET PARTNER=N’TCP：/SERVER1H: 5022’

–-在SERVER2（鏡像）上執行

ALTER DATABASE NOTHWIND   SET PARTNER=N’TCP:/SERVER2: 5022’

    --在SERVER1（主體）上執行

ALTER DATABASE NOTHWIND  SET WITNESS=N’TCP:/SERVER3: 5022’

    --在SERVER1（主體）上執行

ALTER DATABASE  NOTHWIND SET SAFETY FULL;

    --在SERVER1（主體）上執行  高可用性

 

固然也可使用SMSS

 

那麼完成以後怎麼來查看數據庫鏡像是否完成，能夠經過如下兩種方法：

SMSS  數據庫屬性---鏡像狀態

T-SQL

SELECT  * FROM SYS.DATABASE——MIRRORING

SELECT *  FROM SYS.DATABASE——MIRRORING——WITNESS

 

下面咱們具體看一下配置高可用性數據庫鏡像

咱們使用T-SQL 能夠很明顯的看到配置的過程。

下面我來介紹一下咱們所使用的環境：

SERVER1爲主體服務器

SERVER2爲鏡像服務器

SERVER3 爲見證服務器

 

首先咱們要

準備數據庫：一個是備份主體數據庫，一個是在鏡像服務器上恢復。

因此

在SERVE1上： 

   BACKUP DATABASE NORTHWIND TO DISK=’C:\NW.BAK’

在 SERVER2上：

  RESTORE DATABASE NORTHWIND FROM DISK=’C:\NW.BAK’ WITH NORECOVERY

 

 建立數據庫端點：

1．  在SERVER1上建立數據庫鏡像端點，用於夥伴通信

Create endpoint dbmirrep as tcp (listener_port=5022)

For database_mirroring (role=partner,encryption=supported );

Alter endpoint dbmirrep state=started

經過圖形界面能夠查看到

2．  在SERVER2上建立數據庫端點，也是用於夥伴通信

Create endpoint dbmirrep as tcp (listener_port=5022)

For database_mirroring (role=partner,encryption=supported)

Alter endpoint dbmirrep state=started

3．  在SERVER3上建立鏡像端點，用於見證通信

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

也能夠經過圖形界面查看

配置數據庫鏡像安全性：也就是指定哪些用戶可使用這個端點。確定是管理員，通常用戶不讓他訪問。

分別執行:

 

Grant connect on endpoint::"dbmirrep" to "server1\dufei"  

Grant connect on endpoint::"dbmirrep" to "server2\dufei"   

Grant connect on endpoint::"dbmirrep" to "server3\dufei" 

 

最後一個就是啓動數據庫鏡像。注意：順序  首先要從鏡像服務上配置

在SERVER2上，指定夥伴端點：

ALTER DATABASE ITET SET PARTNER='TCP://SERVER1:5022'

在SERVER1上，指定夥伴端點：

ALTER DATABASE itet SET PARTNER='TCP://SERVER2:5022' –查看數據庫

--到此爲止，就是我們前面所介紹的高級別保護模式。能夠實現數據完整性，可是不能實現高可用性。因此還要繼續，也就是說到這裏爲止，不要見證服務器也能夠，可是不能實現故障的自動轉移：

在 SERVER1上，指定見證服務器端點：

Alter  database ITET set wiTness=N'TCP://SERVER3:5022'

設置數據庫鏡像事務安全級別：

ALTER DATABASE ITET SET SAFETY FULL

   

實驗結束,但必定要注意細節

   

最後看一下數據庫鏡像角色切換：也就是如何實現故障轉移

自動故障轉移：

只針對高可用性模式

SAFETY=FULL

 

測試：禁用主服務器的網卡，查看庫狀態，再啓用再查看

 

咱們到這裏已經知道了如何實現數據庫鏡像，那麼用戶如何來使用：客戶端都是鏈接到主體服務器上進行工做的。那麼若是主體服務器不可用了，那麼就會形成用戶鏈接的失敗，它怎麼知道去自動鏈接鏡像服務器，這裏通常使用ADO技術，如ASP.NET 或是微軟所提借的鏈接工具。

咱們這裏藉助WINDOWS 的集羣功能：來進行測試：

SERVER1與SERVER2配置成WINDOWS集羣：

 

實驗到此結束!