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

本文接着前面的章節：SQL Server鏡像簡單介紹　　

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

俗話說：工欲善其事必先利其器。計劃好怎樣部署和使用鏡像，可以下降很是多沒必要要的風險。

本文將依照三步驟的形式展現。但是要注意這不是惟一的標準，詳細狀況詳細分析。

第一步：瞭解環境

　　在搭建SQL Server鏡像時，必須先了解你所要部署的環境。才幹決定鏡像的配置項。

這不只是鏡像配置的前提，也是部署SQL Server甚至搭建數據平臺和其它高可用都應該作的事情。如下是一些常見的需要了解的問題：

1. server是否已經準備好
2. 數據庫是否已經準備好
3. 是否知道所需的服務賬號
4. 是否瞭解數據庫的大小
5. 鏡像server和主體server的性能狀況
6. 是否需要和其它技術組合

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

server是否已經準備好：

　　依據鏡像的要求，必須使用SQL Server 2005 SP1以上的版本號，SP1是第一個全然支持鏡像功能的版本號。理想狀況下。主體server和鏡像server所使用的操做系統和sqlserver的版本號儘可能全然一致。對於SQL Server版本號，必須是企業版或者標準版。除此以外，數據庫的數據文件和日誌文件所在的盤符和文件夾名必須一致，假設不一致，當主體庫把事務發送到鏡像庫時會因爲沒法識別從而引發報錯。

　　假設引入了見證server，可以執行在工做組或者express版本號上。

數據庫是否已經準備好：

　　首先需要確保沒有文件組使用filestream選項。因爲filestream是經過T-SQL操做本地文件，鏡像沒法在鏡像server中讀取主體server上的文件。

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

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

　　在部署過程當中，最簡單的就是使用域帳號。

假設使用一樣的服務賬號。就不需要在端點中受權。

假設使用本地系統賬號執行鏡像，必須使用證書受權來替代Windows受權。當使用證書時。需要注意證書的過時時間。和其它最佳實踐同樣，假設不能使用域帳號，建議使用專用的帳號操做

是否瞭解數據庫的大小：

　　假設需要作鏡像的庫很是大，在初始化的過程當中就要考慮到可能的風險。因爲通常步驟是先作完整備份，而後傳輸備份到鏡像server而後再還原。而後再在主體數據庫上作日誌備份再還原到鏡像中，這個步驟可能需要好幾個小時。

假設此時業務自己就比較繁忙。加上鏡像庫需要追上主體庫的進度，會致使嚴重的性能問題，最起碼網絡傳輸壓力會很是大。

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

 

鏡像server和主體server的性能狀況：

　　理想狀況下。鏡像server的性能應該接近主體server。因爲在Failover的時候可能會短時間接管主體server的所有請求，假設鏡像server性能過低，會致使用戶響應速度變慢。極端狀況下，鏡像server可能會在短時間內承受不了原主體server帶來的壓力直接崩潰。也就是說鏡像server可能也會中止響應。這會致使搭建鏡像的初衷蕩然無存。畢竟搭建鏡像主要就是針對這樣的狀況。

 

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

　　在企業級應用中。很是少僅僅使用單純的一種高可用技術，可能會使用鏡像搭配複製、日誌傳輸甚至集羣。

當混合使用的時候，需要更嚴謹的測試。興許將會提到。

 

第二步：瞭解應用程序：

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

1. 應用程序是怎樣連到server的
2. 是否有不支持本身主動Failover的組件
3. 應用程序是否依賴其它庫
4. 應用程序是否依賴外部資源

應用程序是怎樣連到server的：

　　假設需要支持鏡像。應用程序需要使用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的時候的影響還要制定應對策略。常見的處理手段是把這些組件拷貝到鏡像server並配置鏈接到鏡像庫中。

應用程序是否依賴其它庫：

　　鏡像是庫級的高可用方案，假設應用程序需要使用多個數據庫協同執行時。僅對一個庫作鏡像是不可行的。針對這樣的狀況。可以把所依賴的所有庫都作鏡像，並且使用觸發器檢測鏡像狀態。僅僅要有一個庫的狀態知足Failover。就強制把所有庫都進行Failover。這需要額外的編程。

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

　　假設應用程序依賴本機server的資源，Failover會致使應用程序出現意外，針對這樣的狀況。可以考慮把外部資源放到共享文件夾上，並用UNC地址訪問。

 

第三步：檢驗計劃：

1. 在主體server和鏡像server上創建所需的賬號，建議使用專用的域帳號，並作好歸檔處理，避免其它維護人員或者時間太久以後連本身都不記得帳號password。

2. 鏡像庫不建議使用sa做爲owner。

3. 假設CLR依賴TRUSTWORTHY配置，需要在初始化Failover以後配置。可以經過使用一樣的數據庫owner來解決。即鏡像庫和主體庫在搭建過程當中就要儘量保持全然一致，包含數據庫的owner。

4. 在鏡像配置過程當中確保所有數據庫備份的做業都禁用，完整備份和日誌備份都將影響鏡像server恢復失敗。
5. 確保完整模式下配置鏡像。
6. 確保鏡像server和主體server上相關數據庫的數據文件及日誌文件名稱字、路徑都全然同樣。順帶說一句，系統庫不可作鏡像。

 

實踐建議：

1. 使用與主體server性能儘量接近的鏡像server。

2. 使用專用網絡用於鏡像環境的傳輸數據。網絡和磁盤I/O每每是鏡像和其它高可用技術的常見瓶頸。特別是在大事務量傳輸時。
3. 在高性能模式下不要使用見證server。不然有引發服務丟失的風險，當見證不能鏈接主體或鏡像時，另一個夥伴會因爲丟失仲裁而offline。

4. 使用一樣的盤符和文件路徑。
5. 在測試環境中進行壓力測試。確保鏡像環境不是一個幌子，而是真正能協助業務連續性的功能。
6. 在生產環境中。先使用異步方式執行，假設性能知足。切換到同步模式，假設同步模式也知足，再加入見證server。
7. SQL Server最好使用2005 的SP2（帶有CU6）。或者2008。推薦使用2008R2。
8. 確保鏡像和主體server是一樣的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. 確保鏡像所需的port沒有被佔用，搭建一文會延時。鏡像需要某些port，儘管不強制。但是要指定，因此網絡不只要連通，還要port可Telnet，防火牆的配置也要考慮。

本文中沒有針對每個點進行展開，但是儘量會在後面的幾篇中進行解決。

域環境下鏡像搭建和非域環境下鏡像搭建可以看接下的兩篇文章：

配置SQL Server鏡像——非域環境：http://blog.csdn.net/dba_huangzj/article/details/27652857
配置SQL Server鏡像——域環境：http://blog.csdn.net/dba_huangzj/article/details/28904503