數據庫鏡像（SQL Server Mirroring）從SQL Server 2005 SP2開始引入，雖然從2008開始被列爲"將會被棄用"的功能，但是由於其有很多優勢，一直被廣泛使用至今。 SQL Server 2012發佈後，在官方的聯機手冊中出現了新的聲明：後續版本的 Microsoft SQL Server 將刪除數據庫鏡像功能。請避免在新的開發工作中使用該功能，並着手修改當前還在使用數據庫鏡像的應用程序，以便改用 AlwaysOn 可用性組。
術語：
本系列將會用到很多鏡像甚至高可用的術語，所以這裏先介紹相關概念：
主體服務器，Principal：在鏡像環境中，包含活動庫的源服務器，可以理解爲主服務器。
鏡像服務器，Mirror：在鏡像環境中，包含目標數據庫的服務器，即鏡像環境中的目標服務器。
見證服務器，Witness：可選的一個服務器，用於監控主體服務器和鏡像服務器，最主要的作用是進行自動故障轉移（automatic Failover）。
夥伴服務器，Partner：相對於鏡像環境而言，鏡像服務器就是主體服務器的夥伴服務器，而主體服務器也是鏡像服務器的夥伴服務器。
端點，Endpoint：綁定到網絡協議中的對象，允許SQL Server通過端點在網絡間交互。
會話，Session：活動於鏡像環境中，用於維護服務器之間的狀態信息和關係。簡單來說就是鏡像環境中各個夥伴服務器之間信息的傳遞者。
運行模式，Operating Mode：表示鏡像環境的安全級別，鏡像的運行模式有三種：帶有自動故障轉移的高安全性模式（帶有見證服務器的同步模式），不帶有自動故障轉移的高安全性模式（沒有見證服務器的同步模式），高性能模式（沒有見證服務器的異步同步）。
角色，Role：在鏡像環境中的功能，同一時刻，一個特定的服務器只能是三種角色中的其中一種：主體、鏡像或見證。
運行模式：
從大層面來說，SQL Server鏡像只有兩種模式：高安全模式和高性能模式。兩種模式的主要區別在於在事務提交後的操作。
在高性能模式下，主體服務器不需要等待鏡像服務器響應即可提交事務。
在高安全性模式，需要把事務同步到鏡像並得到響應後才最終提交主體服務器的事務。
高安全模式，High-Safety Mode：
這種模式是同步模式，可以細分爲帶有自動故障轉移（即有見證服務器）的高安全模式和不帶自動故障轉移（即沒有見證服務器）的高安全性模式。如果沒有配置見證服務器，那麼【帶自動故障轉移功能的高安全性(同步)】選項將會爲灰色，即不可選。
兩者最大的區別在於是否引入見證服務器，前面提到過，見證服務器能作爲仲裁，偵測主體服務器的狀態，一旦見證服務器不能連接主體服務器，將把會話自動切換到鏡像服務器，如果沒有見證服務器，那麼需要手動切換。
在高安全模式下，事務必須在鏡像庫上提交，才能在主體庫提交，這也意味着整套程序都必須等待鏡像提交事務後才能最終提交，如果在網絡情況不理想，將影響整個運行過程。高安全模式支持標準版和企業版，並且主體和鏡像服務器必須是相同版本，比如不能一個是標準版，一個是企業版。
如果需要最高級別的鏡像安全性，可以使用見證服務器作爲仲裁，見證服務器不是必須的，但是卻是自動Failover（故障轉移）功能必須的。見證服務器可以使用Workgroup（工作組版）或者Express版。
見證服務器用於檢查鏡像環境中，主體庫和鏡像庫的聯接是否正常。見證服務器並不實際執行Failover，僅僅是告知鏡像服務器："主體服務器宕機了"。即使見證服務器也宕機了，僅僅是不能自動Failover而已，不影響鏡像環境。可以把見證服務器理解爲，僅用於回答：主體服務器是否已經宕機了？圖1-2 是帶有見證服務器的高安全性模式的示意圖
當出現性能問題的時候，可以根據圖1-2的步驟來一步一步偵測。
高性能模式，High-Performance Mode：
這種模式是異步模式，只能手動Failover，所以沒有必要設置見證服務器（實際上是可以設置，但是沒有任何意義。）。這種模式會有數據丟失的可能。和高安全性模式相比，這種模式不需要等待鏡像服務器的確認，所以在網絡條件不理想的環境下，是不錯的選擇。圖1-3是高性能運行模式的示意圖。
同步、異步處理：
從圖1-1 中可以看到，三種運行模式又可以分爲兩類處理，同步和異步。當鏡像運行在同步模式下時，數據庫的SAFETY選項爲FULL。當鏡像爲異步時，數據庫SAFETY的選項爲OFF。兩種高安全模式均爲同步模式，高性能模式使用異步處理。表1-1 列出了兩種模式的主要特點：
SQL Server鏡像的運行模式及其重要，直接影響到配置、預算及故障偵測和性能優化。需要在前期做好評估，並且選擇滿足當前SLA要求的模式。
會話：
在配置完數據庫鏡像之後，就可以開始鏡像會話。在鏡像環境的所有服務器交互過程中，都通過會話來維護對方的狀態信息。開始會話本質上就是開始主體數據庫和鏡像數據庫的同步進程。
暫停和恢復會話：
當服務器出現性能問題時，暫停數據庫會話可以臨時停止因爲鏡像帶來的壓力，但是要注意，暫停會話會導致日誌依舊活動，並且無法截斷，如果時間持續太久，會引起日誌文件的迅速增長，帶來一系列的性能問題。日誌相關問題可以查看《SQL Server掃盲》中關於日誌備份的文章。地址：http://blog.csdn.net/dba_huangzj/article/details/26844859
鏡像狀態：
SQL Server鏡像狀態可能包含下面幾種：
SYNCHRONIZING：正在同步，通常在第一次啓用數據庫鏡像時出現，表示鏡像服務器正在追上主體服務器的進度。
SYNCHRONIZED：已經同步完畢，大部分時間都是這種狀態，一旦有爆發性的事務傳輸到鏡像數據庫，狀態會從SYNCHRONIZED轉變成SYNCHRONIZING。在高安全性模式下，這種狀態通常不會導致數據丟失，僅表示鏡像服務器正在同步，但是在高性能模式下，可能有數據丟失的風險。
SUSPENDED：掛起，當主體服務器不發送事務到鏡像服務器時出現，在Failover發生後會出現這種狀態（如果鏡像環境依舊運行，僅使用Failover則不出現，但是如果鏡像庫斷開連接，則會出現）。手動暫停鏡像會話或者redo 日誌發生錯誤時都會出現。
PENDING_FAILOVER：僅當主體服務器變成鏡像服務器並且斷開用戶連接時，會在原主體服務器出現這種狀態。在這種狀態下，主體服務器和鏡像服務器都會表現這種狀態。但是見證服務器會出現：CONNECTED/DISCONNECTED/UNKNOWN的其中一種狀態。
CONNECTED：代表見證服務器能連到其中一個夥伴，另外兩種代表不能連到夥伴服務器，這種情況下，數據庫會變成不可用，如果鏡像環境使 用了見證，而鏡像服務器爲DISCONNECTED，並且鏡像服務器奔潰，那麼數據庫（即使在主體服務器上）都會變得無法訪問。所以當見證爲disconnected，可以關閉見證，從而禁用仲裁，使用ALTER DATABASE <DB> SET WITNESS OFF實現。
DISCONNECTED：當鏡像環境中的夥伴均無法連接對方時出現。
可以使用sys.database_mirroring目錄視圖查看鏡像信息。
其他高可用對比
截至SQL Server 2012爲止，內置的高可用功能有集羣（Cluster）、鏡像（Mirroring）、複製（Replication）、日誌傳送（Log Shipping）和AlwaysOn（2012出現）。其中AlwaysOn基本上已經實實現了集羣、鏡像的組合功能，所以本文不把鏡像和AlwaysOn比較。僅對其他部分比較。詳細信息可以看官方文檔：http://msdn.microsoft.com/zh-cn/library/ms190202(v=sql.105).aspx
下面簡要介紹一下鏡像和其他部分的對比：
集羣（Cluster）
優點：
這部分特指2012之前的Cluster，它基於Windows 的故障轉移集羣，可以自動檢測SQL Server的健康狀態，進行自動故障轉移切換（自動Failover）。並且它的切換時間幾乎等於SQL Server服務啓動時間，除非有大量事務需要redo，否則一般不會延時很久，和帶有見證服務器的高安全運行模式一起被稱爲2012之前的0延時高可用技術。另外兩種都不能實現自動切換及0延時。
通過虛擬網絡名稱，客戶端可以透明訪問活動實例，而不用修改程序的連接字符串，這一點比鏡像有進一步的改進，鏡像由於只有一個鏡像庫，所以在第一次Failover成功之後，如果不做處理，鏡像環境中原主體庫即使重新聯機。
從2008開始可以指定對非活躍節點進行升級維護。
缺點：
使用共享磁盤，如果共享磁盤出問題，整個Cluster都會癱瘓。
非活躍節點一直處於停止狀態，不能分攤負載，也造成資源浪費。
實施成本高，需要最少3臺機且必須在域中。
故障轉移是整個實例的，和鏡像不同，如果只有某個或者少數幾個庫出現問題需要Failover，鏡像可以進行單獨轉移，但是Cluster不可以，這樣會導致少數不相關的庫受牽連。
複製（Replication）
複製天生就不是一種高可用技術，實際上是用來進行數據同步而已。如果單純進行高可用方案，複製不是一個首選方案。
優點：
實現對象級別的同步，可以細化到列和行。
訂閱庫（也就是複製環境下的目標庫）是可讀的，可以進行讀寫分離方案。
支持多個庫訂閱一個庫。延時可以達到秒級。
可以使用不同的SQL Server版本。
缺點：
不提供自動故障轉移。
不保證對象0丟失。
故障偵測較爲困難，錯誤信息往往不能很明顯地表現出問題。
對錶的定義有一定限制，比如事務複製要求表必須有主鍵。
日誌傳送（Log Shipping）
優點：
目標庫可作爲報表使用。並且過程中對主體服務器的壓力很小。
支持冗餘多個副本，可進行遠程暖備。
機制簡單，故障偵測較爲容易。
缺點：
不支持不同版本的SQL Server。
延時是一定有的，不能實現完全同步。
不支持自動偵測和轉移。
還原日誌時，目標庫不能對外訪問。
同步以庫爲單位。
