熱點推薦:
您现在的位置: 電腦知識網 >> 編程 >> SQL Server >> 正文

幾個技巧解析SQL Server群集的難題[2]

2013-11-15 14:52:43  來源: SQL Server 

  為了將停機時間減到最少您很可能必須使用日志傳送除非您的數據庫相當小並且在一段時間內沒有用戶建立連接在移交之前您都可以正確執行日志傳送接著刪除這些用戶剪切並傳送最後的日志然後指向新實例上的應用程序(有關感興趣的日志傳送替代方法請參閱下面的數據庫鏡像部分)如果使用DNS別名您甚至可能不需要指向新實例上的應用程序而是只需更新 DNS 別名這種方法的優點是如果您的遷移只進行了一部分但必須要回退到原始狀態那您至少還有原始文件

  您還可以采用一種成本較低的方案但需要您做更多的預先規劃一個群集可以支持多個SQL Server實例但每個實例必須有其自己的磁盤資源因此在劃分SAN時請留出一個LUN以備將來升級要執行升級請在此磁盤資源上安裝 SQL Server 二進制文件您可以演習一下該系統當您准備好後關閉當前SQL Server將磁盤資源從舊的 SQL Server組中移出更新依賴關系然後使新SQL Server實例在線連接舊實例中的數據庫然後啟動並運行(您已提早備份了所有數據對嗎?)

  這就是成本較低的方法實行這個方法需要承擔一些風險如果出現故障您無法將數據庫與新實例分離開來並放回原來位置您的操作已簡化為從備份恢復 這意味著需要很長的停機時間

  還有一種方法是將兩個SQL Server實例都放在您的SAN中前提是您有足夠的磁盤空間將生產備份(和日志傳送)恢復為新實例然後按前面介紹的步驟繼續進行但現在您有退路了而且一旦完成遷移您還可以釋放舊實例占用的SAN資源您只需增加額外的磁盤

  負載平衡

  讓我們首先揭穿這樣一個常見誤解MSCS群集是用於獲得高可用性的而非用於實現負載平衡此外SQL Server沒有任何內置的自動負載平衡功能您必須通過應用程序的物理設計來實現負載平衡這意味著什麼?

  隨著表的逐漸增長您可能會預料到性能會降低特別是在涉及到表掃描操作時當行數達到數百萬或數十億時傳統的解決方案會使用已分區視圖這種視圖由若干具有相同結構使用 union ALL 掛接在一起的表組成此外還會在適當位置放置 CHECK 約束來區分這些成員表而這會阻止跨已分區視圖復制數據如果在 CHECK 約束中使用的列也是主鍵的一部分則該視圖是可更新的

  如果成員表在其自己的文件組中則如果這些文件組中的文件分別位於不同的物理驅動器上那麼您會獲得更佳的磁盤性能這些表甚至也可以位於不同的數據庫中但是在SQL Server 只要所有數據均在同一個數據庫中您就可以使用表分區而表分區實現起來就容易得多了

  但是假設您已經盡可能地利用了表分區或(本地)已分區視圖但性能仍然很低如果您擁有SQL Server 或SQL Server 就可以利用分布式已分區視圖了主要差別在於成員表可以位於不同的 SQL Server 實例上而且這些實例可以安裝在 N+ 群集上為什麼鼓勵您這樣做?如果已分區視圖中的任何一個成員表轉入離線狀態則整個視圖也將轉入離線狀態使這些成員成為群集的一部分可以為您提供支持性能和實現負載平衡所需的可靠性

  您真的需要群集嗎?

  或許您有一些備用服務器無事可做但這些服務器不在 Windows 目錄的群集部分中如果您在這些服務器可用的情況下只是為了支持群集就必須出去購置新服務器那麼這是一種浪費可恥的行為

  數據庫鏡像可能是最適合替代群集的一種方法鏡像涉及到三個元素存儲鏡像數據庫的實例稱為主體;備份服務器稱為鏡像;如果要實現自動故障轉移還需要第三台服務器稱為見證方簡而言之主體上的數據庫中的事務會在鏡像中再次運行當主體出現故障時如果有見證方數據庫會自動故障轉移到鏡像您必須為每個應用程序數據庫設置鏡像但不能鏡像系統數據庫

  鏡像是單獨的SQL Server 實例與群集不同的是鏡像可以位於幾千英裡以外其高速緩存中填充的是由於從主體中復制事務而發生的更新活動當然還可以假設除了從主體接收鏡像事務之外鏡像上沒有其他活動既然 SQL Server 已經在鏡像中運行所以故障轉移的速度通常要比在群集中快由於至少有部分高速緩存已准備好所以初始性能並不像在群集方案中那樣低另請注意當鏡像數據庫發生故障轉移時主體和鏡像會互換角色

  數據庫鏡像的不足之處是需要的總磁盤容量是群集的兩倍如果您想在同步模式下運行且不想丟失任何數據那麼您還會需要更多的 CPU 處理能力正如我所說的要想實現高可用性需要花費很高的成本

  組合方法

  由於鏡像與主體之間的距離可以相當遙遠所以對於災難恢復 (DR) 計劃來說選擇鏡像是非常明智的群集是您的第一道防線但是如果您要同時利用群集和鏡像那會出現什麼情況呢?在群集故障轉移中如果您的鏡像配置中有見證方則當群集 SQL Server 轉入在線狀態時鏡像會成為主體但是請注意從新主體回到(群集的)新鏡像的故障轉移不是自動進行的因此當與群集結合使用時最好不要對您的鏡像數據庫啟用自動故障轉移

  災難恢復並不是您使用鏡像的唯一原因;當您必須向主體應用服務包或修補程序時鏡像也是非常有用的在這種情況下您可以手動故障轉移到鏡像在應用服務包或修補程序時舊的主體服務器暫時處於離線狀態在新主體上發生的已提交事務會排隊等候等待被發送回新鏡像(舊主體)在完成服務包或修補程序的安裝之後將會進行同步最終這兩台服務器將完全處於同步狀態現在您便可以在主體和鏡像之間轉換角色了故障轉移與恢復只需要幾秒鐘的停機時間您可以使用這種方法將 SQL Server 遷移到另一台計算機只是不能實現故障恢復

  虛擬服務器添加靈活性

  虛擬化允許您在一台物理服務器上並行運行一個或多個操作系統虛擬化軟件為群集概念添加了另外一層功能因為您可以將軟件加入群集因此如果主機正在其上運行的服務器出現故障則主機及其來賓 OS 會故障轉移到備份節點這可能是遷移來賓服務器的最簡便方法補充一點來賓 OS 不必具有群集功能因此您可以在運行於某群集中的 Microsoft Virtual Server 之上的來賓 Windows Server 內部運行 SQL Server Workgroup Edition實質上您會間接擁有群集 Workgroup Edition

  在控制之下

  如果您在負責 SQL Server 實現您需要確信您的服務器始終處於可用狀態服務器群集會幫助確保您的服務器始終可用本文提供了一些來之不易的技巧以幫助您入門您可以在群集資源邊欄中找到更多有用信息

[]  []  


From:http://tw.wingwit.com/Article/program/SQLServer/201311/22476.html
    推薦文章
    Copyright © 2005-2013 電腦知識網 Computer Knowledge   All rights reserved.