第三篇——第二部分——第二文 計劃搭建SQL Server鏡像

本文緊跟上一章：SQL Server鏡像簡介　　

本文出處：http://blog.csdn.net/dba_huangzj/article/details/27203053

俗話說：工欲善其事必先利其器。計劃好如何部署和使用鏡像，可以減少很多不必要的風險。本文將按照三步驟的形式展示，但是要注意這不是唯一的標準，具體情況具體分析。

第一步：瞭解環境

　　在搭建SQL Server鏡像時，必須先瞭解你所要部署的環境，才能決定鏡像的配置項。這不僅是鏡像配置的前提，也是部署SQL Server甚至搭建資料平台和其他高可用都應該做的事情。下面是一些常見的需要瞭解的問題：

1. 伺服器是否已經準備好
2. 資料庫是否已經準備好
3. 是否知道所需的服務帳號
4. 是否瞭解資料庫的大小
5. 鏡像伺服器和主體伺服器的效能情況
6. 是否需要和其他技術組合

　　下面詳細介紹一下這6點：

伺服器是否已經準備好：

　　根據鏡像的要求，必須使用SQL Server 2005 SP1以上的版本，SP1是第一個完全支援鏡像功能的版本。理想情況下，主體伺服器和鏡像伺服器所使用的作業系統和sqlserver的版本盡量完全一致。對於SQL Server版本，必須是企業版或者標準版。除此之外，資料庫的資料檔案和記錄檔所在的盤符和目錄名必須一致，如果不一致，當主體庫把事務發送到鏡像庫時會因為無法識別從而引起報錯。

　　如果引入了見證伺服器，可以運行在工作群組或者express版本上。

資料庫是否已經準備好：

　　首先需要確保沒有檔案組使用filestream選項，因為filestream是通過T-SQL操作本地檔案，鏡像無法在鏡像伺服器中讀取主體伺服器上的檔案。

　　其次，鏡像環境要求完整復原模式。

是否知道所需的服務帳號：

　　在部署過程中，最簡單的就是使用域帳號。如果使用相同的服務帳號，就不需要在端點中授權。如果使用本地系統帳號運行鏡像，必須使用認證授權來替代Windows授權。當使用認證時，需要注意認證的到期時間。和其他最佳實務一樣，如果不能使用域帳號，建議使用專用的帳號操作

是否瞭解資料庫的大小：

　　如果需要做鏡像的庫很大，在初始化的過程中就要考慮到可能的風險。因為一般步驟是先做完整備份，然後傳輸備份到鏡像伺服器然後再還原，然後再在主體資料庫上做記錄備份再還原到鏡像中，這個步驟可能需要好幾個小時。如果此時業務本身就比較繁忙，加上鏡像庫需要追上主體庫的進度，會導致嚴重的效能問題，最起碼網路傳輸壓力會很大。

　　針對這種情況，可以使用log shipping功能進行傳輸，注意使用NORECOVERY選項而不要用STANDBY選項。在搭建鏡像一文中會提到，鏡像庫需要使用NORECOVERY狀態。

 

鏡像伺服器和主體伺服器的效能情況：

　　理想情況下，鏡像伺服器的效能應該接近主體伺服器，因為在Failover的時候可能會短期接管主體伺服器的所有請求，如果鏡像伺服器效能太低，會導致使用者響應速度變慢。極端情況下，鏡像伺服器可能會在短期內承受不了原主體伺服器帶來的壓力直接崩潰，也就是說鏡像伺服器可能也會停止回應，這會導致搭建鏡像的初衷蕩然無存。畢竟搭建鏡像主要就是針對這種情況。

 

是否需要和其他技術組合:

　　在企業級應用中，很少只使用單純的一種高可用技術，可能會使用鏡像搭配複製、日誌傳輸甚至叢集。當混合使用的時候，需要更嚴謹的測試，後續將會提到。

 

第二步：瞭解應用程式：

　　除了瞭解鏡像環境的硬體部分，也要瞭解軟體部分，也就是運行在這個環境下的應用程式，這些應用中，有些是“黑盒”，特別是第三方軟體。對於這方面的內容，需要考慮的有：

1. 應用程式是如何連到伺服器的
2. 是否有不支援自動Failover的組件
3. 應用程式是否依賴其他庫
4. 應用程式是否依賴外部資源

應用程式是如何連到伺服器的：

　　如果需要支援鏡像，應用程式需要使用SQL Native Client、ADO.NET 2.0 Data Provider或者JDBC 1.1 Driver for SQL Server。並且連接字串需要使用Failover partner屬性。如果搭建了鏡像，而不添加Failover Partner屬性，那麼就要每次在Failover時手動修改應用程式的連接字串，這會影響程式的業務持久性。

是否有不支援自動Failover的組件：

　　如果如DTS包、SSIS包或者外部應用使用了不支援鏡像的連線協定，需要評估在進行Failover的時候的影響還要制定應對策略。常見的處理手段是把這些組件複製到鏡像伺服器並配置串連到鏡像庫中。

應用程式是否依賴其他庫：

　　鏡像是庫級的高可用方案，如果應用程式需要使用多個資料庫協同運行時，僅對一個庫做鏡像是不可行的。針對這種情況，可以把所依賴的所有庫都做鏡像，並且使用觸發器檢測鏡像狀態，只要有一個庫的狀態滿足Failover，就強制把所有庫都進行Failover。這需要額外的編程。

應用程式是否依賴外部資源：

　　如果應用程式依賴本機伺服器的資源，Failover會導致應用程式出現意外，針對這種情況，可以考慮把外部資源放到共用資料夾上，並用UNC地址訪問。

 

第三步：檢驗計劃：

1. 在主體伺服器和鏡像伺服器上建立所需的帳號，建議使用專用的域帳號，並做好歸檔處理，避免其他維護人員或者時間過久之後連自己都不記得帳號密碼。
2. 鏡像庫不建議使用sa作為owner。
3. 如果CLR依賴TRUSTWORTHY配置，需要在初始化Failover之後配置。可以通過使用相同的資料庫owner來解決。即鏡像庫和主體庫在搭建過程中就要儘可能保持完全一致，包括資料庫的owner。
4. 在鏡像配置過程中確保所有Database Backup的作業都禁用，完整備份和記錄備份都將影響鏡像伺服器恢複失敗。
5. 確保完整模式下配置鏡像。
6. 確保鏡像伺服器和主體伺服器上相關資料庫的資料檔案及記錄檔名字、路徑都完全一樣。順帶說一句，系統庫不可做鏡像。

 

實踐建議：

1. 使用與主體伺服器效能儘可能接近的鏡像伺服器。
2. 使用專用網路用於鏡像環境的資料轉送，網路和磁碟I/O往往是鏡像和其他高可用技術的常見瓶頸。特別是在大事務量傳輸時。
3. 在高效能模式下不要使用見證伺服器，否則有引起服務丟失的風險，當見證不能串連主體或鏡像時，另外一個夥伴會因為丟失仲裁而offline。
4. 使用相同的盤符和檔案路徑。
5. 在測試環境中進行壓力測試。確保鏡像環境不是一個幌子，而是真正能協助商務持續性的功能。
6. 在生產環境中，先使用非同步方式運行，如果效能滿足，切換到同步模式，如果同步模式也滿足，再添加見證伺服器。
7. SQL Server最好使用2005 的SP2（帶有CU6），或者2008，推薦使用2008R2。
8. 確保鏡像和主體伺服器是相同的SP和SQL Server版本。
9. 使用相同的定序。
10. 維護計劃不支援鏡像功能，需要額外編程，針對sys.databases中的state欄位做處理。在《SQL Server鏡像日常維護》一文中介紹。
11. 儲存鏡像的配置指令碼及檔案。以便快速重建及版本管控。
12. 不要把夥伴的timeout時間設為小於10秒。過小的timeout會影響鏡像的正常運行，但是從實踐來說，並不是越長越好，一般上限是30~50秒。
13. 初始化鏡像時可以臨時使用logshipping同步。Logshipping也可以作為高效能模式下的協助工具功能。
14. 監控msdb中suspect_pages系統資料表，用於修複torn pages。
15. 避免使用相同的交換器或者路由器用於串連主體和鏡像。主要原因是避免因為交換器、路由器同時出現故障而影響整個網路環境。
16. 確保鏡像所需的連接埠沒有被佔用，搭建一文會延時。鏡像需要某些連接埠，雖然不強制，但是要指定，所以網路不僅要連通，還要連接埠可Telnet，防火牆的配置也要考慮。

本文中沒有針對每個點進行展開，但是儘可能會在後面的幾篇中進行解決。域環境下鏡像搭建和非域環境下鏡像搭建可以看接下的兩篇文章：配置SQL Server鏡像——非域環境：http://blog.csdn.net/dba_huangzj/article/details/27652857
配置SQL Server鏡像——域環境：http://blog.csdn.net/dba_huangzj/article/details/28904503