利用SQL SERVER 2005數據庫鏡像實現可用性分析，sql可用性

利用SQL SERVER 2005數據庫鏡像實現可用性分析，sql可用性

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

現在幾乎所有的應用系統都是基於數據庫的，那麼數據庫的負荷是比較大的，在一天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集群：

實驗到此結束!

本文出自 “杜飛” 博客

sql server 2005 高可用性鏡像配置問題

數據庫鏡像會話無法避免與客戶端相關的服務器訪問問題，例如，客戶端計算機出現網絡通信問題時。到鏡像數據庫的連接嘗試也可能會因為各種與數據訪問接口無關的原因而失敗；例如，連接嘗試可能會因為下列情況而失敗：主體服務器實例處於不活動狀態（如同數據庫進行故障轉移時發生的情況）或者網絡錯誤。

嘗試連接時，數據訪問接口首先使用初始伙伴名稱。如果指定的服務器實例可用並且為當前主體服務器實例，則連接嘗試通常都會成功。
參考資料：msdn.microsoft.com/zh-cn/library/ms366348(SQL.90).aspx
 

sql server 數據庫鏡像功可以是做什用的？

SQL Server 2005相對於SQL Server 2000來說，無論是性能還是功能都有一個相當大的提高,甚至可以用“革命”來形容這一次升級。SQL Server 2005使 SQL Server 跻身於企業級數據庫行列。在數據高可用性方面，SQL Server 2005為用戶提供了數據鏡像、復制、故障轉移群集、日志傳送功能。本文向讀者簡單介結SQL Server 2005鏡像功能。

　　一、鏡像簡介

　　數據庫鏡像是一個高可用性軟件解決方案，為客戶端提供小於10秒故障轉移。每個數據庫鏡像配置均包含一個主體服務器（包含主體數據庫）、一個鏡像服務器（包含鏡像數據庫）和一個見證服務器，其中見證服務器是可選的。主體服務器和鏡像服務器要求是獨立的服務器實例。主體服務器和鏡像服務器的角色是相對的，可以自動或者手動地將主體服務器設置為鏡像服務器，鏡像服務器設置為主體服務器。與主體服務器和鏡像服務器不同的是，見證服務器並不能用於數據庫。見證服務器監視主體服務器和鏡像服務器，確保在給定的時間內這兩個故障轉移服務器中有且只有一個作為主體服務器，從而支持自動故障轉移。如果存在見證服務器，同步會話將以“高可用性模式”運行，如果主體服務器出現故障，可以實現故障自動轉移。如果見證服務器不存在，同步會話將以“高級別保護模式”運行，出現故障需要手動故障轉移，並且有可能丟失數據。

　　圖1：兩台服務器鏡像

　　圖2：兩台服務器鏡像，一台見證服務器

　　數據庫准備結束，端點創建完成，用戶便可以啟用數據庫鏡像。鏡像啟動後，每個伙伴都將開始維護所在數據庫中有關其數據庫，以及另一個伙伴和見證服務器的狀態信息。這些狀態信息允許服務器實例維護稱為“數據庫鏡像會話”的當前關系。在數據庫鏡像會話過程中，服務器實例將通過彼此定期交換 PING 消息來互相監視。