第三篇——第二部分——第一文 SQL Server鏡像簡介

原文出處：http://blog.csdn.net/dba_huangzj/article/details/26951563

　　鏡像是什嗎？說白了就是個鏡子（沒用過鏡子？沒鏡子你總要小便吧？開個玩笑。。 ），這裡鏡子的含義主要有兩個：1、一模一樣，下面會詳細介紹，包括庫名、資料檔案和記錄檔的存放路徑都要一樣。2、看得到，卻“用不了”，鏡像庫在沒有做任何處理時是不可訪問的。下面進入專業一點的解釋：

　　資料庫鏡像（SQL Server Mirroring）從SQL Server 2005  SP2開始引入，雖然從2008開始被列為“將會被棄用”的功能，但是由於其有很多優勢，一直被廣泛使用至今。本文將介紹鏡像的基礎，也會介紹和其他SQL Server提供的高可用方案的對比。《SQL Server掃盲》系列將會單獨介紹各種高可用方案，所以這裡不會過多介紹，主要是進行對比。

 

術語：

本系列將會用到很多鏡像甚至高可用的術語，所以這裡先介紹相關概念：

• 主體伺服器，Principal：在鏡像環境中，包含活動庫的原始伺服器，可以理解為主伺服器。
• 鏡像伺服器，Mirror：在鏡像環境中，包含目標資料庫的伺服器，即鏡像環境中的目標伺服器。
• 見證伺服器，Witness：可選的一個伺服器，用於監控主體伺服器和鏡像伺服器，最主要的作用是進行自動容錯移轉（automatic Failover）。
• 夥伴伺服器，Partner：相對於鏡像環境而言，鏡像伺服器就是主體伺服器的夥伴伺服器，而主體伺服器也是鏡像伺服器的夥伴伺服器。
• 端點，Endpoint：綁定到網路通訊協定中的對象，允許SQL Server通過端點在網路間互動。
• 會話，Session：活動於鏡像環境中，用於維護伺服器之間的狀態資訊和關係。簡單來說就是鏡像環境中各個夥伴伺服器之間資訊的傳遞者。
• 運行模式，Operating Mode：表示鏡像環境的安全層級，鏡像的運行模式有三種：帶有自動容錯移轉的高安全性模式（帶有見證伺服器的同步模式），不帶有自動容錯移轉的高安全性模式（沒有見證伺服器的同步模式），高效能模式（沒有見證伺服器的非同步同步）。
• 角色，Role：在鏡像環境中的功能，同一時刻，一個特定的伺服器只能是三種角色中的其中一種：主體、鏡像或見證。

 

運行模式：

　　從大層面來說，SQL Server鏡像只有兩種模式：高安全模式和高效能模式。兩種模式的主要區別在於在事務提交後的操作。可以從圖1-1中查看運行模式。

　　在高效能模式下，主體伺服器不需要等待鏡像伺服器響應即可提交事務。

　　在高安全性模式，需要把事務同步到鏡像並得到響應後才最終提交主體伺服器的事務。

 

注意：不管使用何種模式，主體庫都必須配置為完整復原模式。

 

圖1-1 SQL Server鏡像運行模式

高安全模式，High-Safety Mode：

 

　　這種模式是同步模式，可以細分為帶有自動容錯移轉（即有見證伺服器）的高安全模式和不帶自動容錯移轉（即沒有見證伺服器）的高安全性模式。如果沒有配置見證伺服器，那麼【帶自動容錯移轉功能的高安全性(同步)】選項將會為灰色，即不可選。

　　兩者最大的區別在於是否引入見證伺服器，前面提到過，見證伺服器能作為仲裁，偵測主體伺服器的狀態，一旦見證伺服器不能串連主體伺服器，將把會話自動切換到鏡像伺服器，如果沒有見證伺服器，那麼需要手動切換。

　　在高安全模式下，事務必須在鏡像庫上提交，才能在主體庫提交，這也意味著整套程式都必須等待鏡像提交事務後才能最終提交，如果在網路情況不理想，將影響整個運行過程。高安全模式支援標準版和企業版，並且主體和鏡像伺服器必須是相同版本，比如不能一個是標準版，一個是企業版。

　　如果需要最進階別的鏡像安全性，可以使用見證伺服器作為仲裁，見證伺服器不是必須的，但是卻是自動Failover（容錯移轉）功能必須的。見證伺服器可以使用Workgroup（工作群組版）或者Express版。

　　見證伺服器用於檢查鏡像環境中，主體庫和鏡像庫的聯結是否正常。見證伺服器並不實際執行Failover，僅僅是告知鏡像伺服器：“主體伺服器宕機了”。即使見證伺服器也宕機了，僅僅是不能自動Failover而已，不影響鏡像環境。可以把見證伺服器理解為，僅用於回答：主體伺服器是否已經宕機了？圖1-2 是帶有見證伺服器的高安全性模式的

 

 

圖1-2 帶有見證伺服器的高安全性模式

　　當出現效能問題的時候，可以根據圖1-2的步驟來一步一步偵測。

高效能模式，High-Performance Mode：

 

　　這種模式是非同步模式，只能手動Failover，所以沒有必要設定見證伺服器（實際上是可以設定，但是沒有任何意義。）。這種模式會有資料丟失的可能。和高安全性模式相比，這種模式不需要等待鏡像伺服器的確認，所以在網路條件不理想的環境下，是不錯的選擇。圖1-3是高效能運行模式的。

圖1-3  高效能運行模式

 

同步、非同步處理：

 

　　從圖1-1 中可以看到，三種運行模式又可以分為兩類處理，同步和非同步。當鏡像運行在同步模式下時，資料庫的SAFETY選項為FULL。當鏡像為非同步時，資料庫SAFETY的選項為OFF。兩種高安全模式均為同步模式，高效能模式使用非同步處理。表1-1 列出了兩種模式的主要特點：

表1-1 同步和非同步模式的特點：

模式	版本要求	資料丟失	SAFETY選項	效能影響	恢複速度	容錯移轉
同步	標準/企業	0丟失	FULL	網路可能影響效能	快	可自動
非同步	企業版	有可能遺失資料	OFF	影響較小	根據需要提交的事務量而定	不可自動

 圖1-4 SQL Server鏡像運行模式選擇

                SQL Server鏡像的運行模式及其重要，直接影響到配置、預算及故障偵測和效能最佳化。需要在前期做好評估，並且選擇滿足當前SLA要求的模式。

會話：

 

　　在配置完資料庫鏡像之後，就可以開始鏡像會話。在鏡像環境的所有伺服器互動過程中，都通過會話來維護對方的狀態資訊。開始會話本質上就是開始主體資料庫和鏡像資料庫的同步進程。

暫停和恢複會話：

 

　　當伺服器出現效能問題時，暫停資料庫會話可以臨時停止因為鏡像帶來的壓力，但是要注意，暫停會話會導致日誌依舊活動，並且無法截斷，如果時間持續太久，會引起記錄檔的迅速增長，帶來一系列的效能問題。日誌相關問題可以查看《SQL Server掃盲》中關於記錄備份的文章。地址：http://blog.csdn.net/dba_huangzj/article/details/26844859

SSMS暫停會話：

　　可以通過圖1-5中的方式暫時鏡像會話

 

圖1-5 暫停會話

T-SQL暫停、恢複會話：

　　可在主體庫或者鏡像庫上執行下面的指令碼暫停和恢複會話：

ALTER DATABASE AdventureWorks2008R2 SET PARTNER SUSPEND;--暫停會話ALTER DATABASE AdventureWorks2008R2 SET PARTNER RESUME;--恢複會話

　　當資料庫鏡像會話啟動後，主體伺服器會發送事務給鏡像伺服器，所有未發送到鏡像伺服器的事務都被收集到發送隊列（send queue）。在高安全性模式下，僅在鏡像庫處於暫停狀態時才會建立send queue。如果是高效能模式，不僅鏡像處於暫停，即使伺服器處於高使用率、網路慢、鏡像伺服器上有一個大型redo 隊列或者其他原因都會引起send queue。

　　在鏡像庫中，已經傳送過來但是未被寫入鏡像庫的交易記錄的事務會存放到redo queue中。如果redo操作失敗，鏡像伺服器會暫停會話直到問題解決。

　　關於隊列的介紹，將會在本系列的第六篇《監控和最佳化SQL Server鏡像》中介紹。http://blog.csdn.net/dba_huangzj/article/details/26846203

　　注意：一個資料庫只能有一個鏡像庫，如果需要保持多個副本，可以藉助記錄傳送加鏡像。

鏡像狀態： 

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鏡像可以使用下面三種方式切換角色：

手動Failover：

使用T-SQL語句：

Use mastergoALTER DATABASE <DB> SET PARTNER FAILOVER--在主體伺服器上執行

使用SSMS：

 

圖1-6使用SSMS實現手動Failover

注意：高效能模式下不支援手動切換

自動Failover：

帶有見證伺服器的高安全模式，當主體串連失敗或者停止工作時，會自動切換到鏡像伺服器。當原主體伺服器重新連機時，這台原主體伺服器會變成鏡像環境中的鏡像伺服器。

可能遺失資料的強制切換：

這種切換方式支援沒有見證伺服器的高效能和高安全模式，可以使用下面的T-SQL語句實現：

ALTER DATABASE <DB> SET PARTNER FORCE_SERVICE_ALLOW_DATA_LOSS --在鏡像庫執行

透明用戶端重新導向 ：

由SQL Native Client（SNAC）提供，允許鏡像環境下，應用程式自動重新導向到鏡像資料庫中。通過在連接字串加上Failover_Partner關鍵字來實現。應用程式需要添加重新嘗試聯結的功能。 

SQL Server2008鏡像的改進：日誌流壓縮：

基於最小化網路頻寬帶來的影響，2008引入了日誌流壓縮功能，但是需要注意壓縮和解壓功能天生就會增加CPU的開銷。

自動頁還原：

在過去，頁損壞是很頭痛的事情，並且很難恢複。2008的鏡像功能通過把鏡像庫的對應頁恢複到主體庫的頁上，從而恢複資料。但是有些頁鏡像是不能回複的，比如檔案頭（page 0），資料庫啟動頁（boot page，page 9），SGAM、PFS。但是對於下面的情況，鏡像可以恢複：

• Error 823：OScyclic redundancy check（CRC）failure
• Error 824：logical errors including a bad page checksum or torn write
• Error 829：page has been marked as restore pending

SQL Server鏡像各功能所需版本：

　　一圖抵千言，圖1-7展示了SQL Server鏡像中各個功能所需的版本支援：

 

圖1-7 SQL Server鏡像中各個功能所需的版本支援

其他高可用對比

截至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不可以，這樣會導致少數不相關的庫受牽連。

　　Cluster有譯成群集，不過這個無所謂，大家知道這個意思即可。我個人偏向使用英文。

複製（Replication）

　　複製天生就不是一種高可用技術，實際上是用來進行資料同步而已。如果單純進行高可用方案，複製不是一個首選方案。

優點：

• 實現對象層級的同步，可以細化到列和行。
• 訂閱庫（也就是複製環境下的目標庫）是可讀的，可以進行讀寫分離方案。
• 支援多個庫訂閱一個庫。延時可以達到秒級。
• 可以使用不同的SQL Server版本。

缺點：

• 不提供自動容錯移轉。
• 不保證對象0丟失。
• 故障偵測較為困難，錯誤資訊往往不能很明顯地表現出問題。
• 對錶的定義有一定限制，比如事務複製要求表必須有主鍵。

記錄傳送（Log Shipping）優點：

• 目標庫可作為報表使用。並且過程中對主體伺服器的壓力很小。
• 支援冗餘多個副本，可進行遠程暖備。
• 機制簡單，故障偵測較為容易。

缺點：

• 不支援不同版本的SQL Server。
• 延時是一定有的，不能實現完全同步。
• 不支援自動偵測和轉移。
• 還原日誌時，目標庫不能對外訪問。
• 同步以庫為單位。

 

　　下面借用《SQL Server 2012 實施與管理實戰指南》上的一個表格來總結一下：

功能	Cluster	記錄傳送	鏡像	複製
保護層級	執行個體	庫	庫	資料庫物件
資料丟失	/	可能	同步模式下無	可能有
自動容錯移轉	是	否	高安全模式下是	否
對用戶端是否透明	是	否	是，但需要設定字串	否
停機時間	基於服務重啟	長	等於恢復	長
多備用庫	否	是	否	是
備用副本可讀	/	是	否	是
抵禦誤操作	否	是	否	否
抵禦磁碟故障	否	是	是	是
是否需要特定硬體	Windows叢集	無	要求較好的磁碟和網路	無
對效能影響	低	中	中	高
版本支援	2000開始	2000開始	2005開始	2000開始