數據庫高可用實戰案例-------架構優化之清爽一夏

　　說到高可用,看官們會想到不少方案,也許是自親身經歷過系統從單機變成高可用的痛苦過程,也許有的看官只是在本身的虛機上搭建過測試的玩具。今天本篇用我本身的真實經歷給你們講述，無論怎麼樣實戰和測試玩耍仍是很大的區別的！可能你以爲搭建一套高可用方案很簡單，配置配置就OK了，但在真正的複雜系統中一切就沒有那麼輕鬆了！ 

　　文章主要講述升級並搭建AlwaysOn高可用的過程，以實施的思路爲主。文中並無搭建集羣的步驟，搭建步驟請自行學習(我的認爲會搭建可用組並非關鍵,而一系列的調研細節纔是項目成功的關鍵)。

--------------博客地址---------------------------------------------------------------------------------------

原文地址: http://www.cnblogs.com/double-K/

若有轉載請保留原文地址! 

 

 

廢話很少說，直接開整-----------------------------------------------------------------------------------------

背景

　　客戶的現有方案是一套使用發佈訂閱構建的讀寫分離方案，整體來講系統構建的很不錯。也是在SQL2012以前很常見的一套架構。

　　架構圖以下：

 　　

 

　　

 

 

 

　　客戶的需求：SQL server 2008 R2 升級到SQL SERVER 2014 使用AlwaysOn 替換現有發佈訂閱架構。實現本地高可用、讀寫分離，異地災備等，並應用部分2014的新功能，如內存優化表等提高系統性能和併發能力等。

前期調研

數據收集

　　前期對系統的瞭解很重要！那麼怎麼樣對系統有一個初步直觀而且詳細的瞭解呢？用腳本收集？這是時候就體現出工具的專業和協做價值。工欲善其事，必先利其器！

 

　　

 

　　

　　

　　

 

 

肯定方案

　　經過前期的需求分析，並對客戶系統結構有了一個初步的瞭解後，咱們用了將近一週的時間從架構的複雜度，易用性，客戶程序改動程度，性能，穩定性等多個角度敲定了最終的方案。

　　架構圖以下：

 　　

 

 　　

 

　　從原來那麼複雜的架構變成如此清爽的架構，使用AlwaysOn取代複雜的發佈訂閱，使用AlwaysOn的只讀節點實現讀寫分離，另外使用異地災備節點取代原有的異地發佈數據庫，很不錯吧！這也是用戶最傾向的架構，由於複雜度低，相對穩定易於維護。這裏要注意！凡事有利必有弊！要說「可是」了。

　　可是，升級改動的成本大大提高！

　　爲何這麼說？咱們接着看！

詳細調研

　　這樣的一個複雜的系統前期的詳細調研是須要很長時間的，幾套系統不只僅是架構上設計的比較複雜，功能應用、接口等更是複雜！下面是主要的一些梳理過程：

原有系統結構

　　咱們首先要對原有系統的設計有透徹的瞭解，客戶在兩地分別有一個數據中心，三套系統有大量的業務要使用其餘系統的數據，因此這裏使用發佈訂閱準時時的把其餘系統中的數據發佈到系統中的一個數據庫，並使用同義詞指向訂閱來的數據。這種結構下降了使用連接服務器跨實例甚至跨機房訪問的性能消耗！而且多份數據訂閱到多個只讀的節點，從而實現了報表、接口等業務的讀寫分離。

 

系統對象整理

　　由於要作升級遷移，因此對象的整理是很重要的工做，業務對象的遺漏可能會帶來不可挽回的災難！甚至可能會致使整個升級，架構部署的回滾！幾套系統中涉及的對象列表過於龐大，好比賬號幾十個，幾十個做業，上百個同義詞，實例級觸發器等等.....

服務器劃分：

• 主庫對象
• 讀寫分離各個只讀庫對象
• 發佈到其餘業務系統的數據服務器配置對象
• 其餘應用程序對象

對象劃分：

• 數據庫賬號
• 連接服務器
• 實例級觸發器
• 做業
• 系統參數
• 維護計劃
• cdc
• BI相關
• 同義詞
• 程序集
• 郵件
• 操做員
• 只讀庫多出來的索引、視圖等對象
• 等等等

測試過程

搭建測試環境

　　全部的升級、高可用項目測試環節都是必不可少的。首先是測方案配合業務的可行性，由於做爲第三方公司不能對用戶全部的應用關係，系統架構瞭如指掌，甚至客戶方本身的工程師可能也作不到這一點。其次是測試功能在新環境下是否出現異常。還有就是對收集並遷移的系統對象進行一次查缺補漏。這樣也能夠儘可能保證系統上線時發生故障的機率！

　　測試環境無疑是任何升級、架構變動的必要步驟，也只有通過充分的測試才能作到心中有數，進而實現零故障上線。

上線演練

　　上線演練？這是個什麼東西？

　　首先數據庫的操做必定要肯定可實施的時間窗口！保證在固定的時間窗口完成工做很重要，那麼這就是上線演練的最大好處，咱們使用準備出的新機器徹底模擬上線的所有步驟，並記錄每一個步驟使用的時間，可能出現的風險，最遲的完成時間等等。其次搭建完成後咱們能夠用這個環境（就是完成後正式環境的配置）進行壓力測試。

　　上線演練是一個很必要的步驟，但這個步驟要視實際的狀況而定，好比升級的方式，環境的配置等。在這樣的一個項目中咱們作了兩輪的上線演練！

實施過程

制定性能基線

　　這樣一個大的變更，數據庫在各個階段的性能指標是什麼樣子的呢? 這裏咱們依然使用 Expert for SQL Server 工具對每個階段實施先後性能進行對比，這樣不只能對實施的影響進行監控，更能清晰地分析出每一個實施階段對性能的影響！

　　

 

　　

 

對每一個指標也都作相應的對比分析，指標比較多這裏不一一介紹了，請參見優化系列文章：

SQL SERVER全面優化-------Expert for SQL Server 診斷系列

性能優化

　　這裏的性能優化，咱們主要針對語句系統的一些常規參數、慢語句進行第一輪的優化！另一個重點就是爲了應對升級到2014後可能變慢的語句進行調整！具體什麼樣的語句可能變慢？ 這個...

• 系統的重點語句（執行最頻繁的）
• 語句複雜的
• 大面積測試吧.....哈哈哈

　　這裏爲何要在升級前就做這樣的優化工做而不是升級後系統運行時在針對慢的語句進行分析呢? 這個道理很簡單,若是上線了才發現若是變慢的功能不少,或變慢的是頻繁的功能那麼上線的效果就是倆個字"失敗"。雖然有的看官知道可使用提示或下降兼容級別解決這個問題，可是這只是特殊場景下的極端手段，而並非解決的根本。因此建議若是你有升級到2014的須要，那麼這樣的優化手段必定要提早作！

升級到2014

　　升級數據庫徹底能夠寫成好幾篇博客，甚至寫本小書均可以了！這裏只作簡單介紹，和一些要重點注意的問題！

　　升級方式

　　升級方式有2種：in place 和side by side，這裏採用的是side by side！ 通俗地說就是準備新的服務器，安裝對應版本的數據庫，而後把數據還原上去。side by side的好處就是升級不會影響原有的環境，即便失敗也能修改程序指向回退到原環境！

　　

 

　　升級2014 最大的一個問題

　　2014 的新特性 「參數估計」 ！這個讓人興奮又苦惱的新功能會致使不少語句在升級到2014 後變慢，由於前面的優化階段已經對這部分重點關注了，因此這部分的問題基本已經消滅！可是萬惡的分區表（200多個分區）依然致使了批處理的性能嚴重問題！

集羣搭建

　　集羣搭建可能沒有過多的可說支出，正常建立故障轉移集羣，搭建AlwaysOn等，但這其中的細節仍是不少的，好比仲裁的方式？異地節點的虛擬IP設置？節點個數與業務的配合？等等等的問題，這裏也就不一一細說了。

　　詳細步驟請按照 樺仔很是詳細的三篇博文:從0開始搭建SQL Server AlwaysOn 第三篇（配置AlwaysOn）

第一篇
http://www.cnblogs.com/lyhabc/p/4678330.html

第二篇
http://www.cnblogs.com/lyhabc/p/4682028.html

第三篇

http://www.cnblogs.com/lyhabc/p/4682986.html

程序修改

　　這個架構的修改也必然致使程序上的變化，這也是前文中提到的爲何客戶最傾向的架構，由於複雜度低而使成本大大提高。原始系統中的關聯性沒法經過發佈訂閱實現本地化訪問，又不能使用性能很是差的連接服務器。那麼路只有一條，那就是修改程序訪問方式，簡單理解爲在程序中分別在各自的數據庫中查出相應的數據，而後經過程序在內存中操做處理。

細節問題處理

　　整體的實施步驟能夠說就是這樣了，可是在這個總體步驟中充斥着無數的細節，每個細節可能都決定着方案的可行性，升級、架構變動的成敗。限於篇幅這裏只舉幾個可能常見的問題說明一下！

• CDC功能與AlwaysOn：官方文檔上說CDC與AlwaysOn能夠實現轉移後CDC不間斷，可是通過測試CDC做業在AlwaysOn切換後屢次執行失敗則不會再一次自動運行，CDC的logreader和發佈訂閱時同樣的，但在沒有發佈訂閱存在的狀況下只有CDC做業會出現上述問題。解決辦法：配置調控做業（節點切換做業控制）
• 重建索引操做：因爲配置異地節點。日誌重建變成問題，測試中重建索引的日誌量是單機下日誌量的好幾倍！這樣會致使異地日誌隊列過長。解決辦法：使用手工腳本拆分細化索引重建，根據隊列大小和傳輸速率控制天天的日誌量。
• 2014下語句變慢：具體就不細說了，2014參數估計和200+分區表組合產生的語句變慢問題至今沒有答案。目前只是使用一些方法避免了這個問題！（這個問題也請遇到的朋友給些思路，謝謝）
• 只讀副本上有寫操做：因爲一些報表操做使用中間臨時表，這裏臨時表不是#temp 這種而是真正的物理表做爲臨時表。解決方案：修改成臨時表，或建立單獨數據庫（不在可用性組中），在使用同義詞指向新庫實現寫操做。

 

　　遇到的問題真的是各類多，這也是爲何說當你的常規技術手段都掌握的時候，踩過的坑就是你的成長了！

 

--------------博客地址---------------------------------------------------------------------------------------

原文地址: http://www.cnblogs.com/double-K/

若有轉載請保留原文地址! 

 

-----------------------------------------------------------------------------------------------------

 

　　總結 ： 文章只是簡單分享了一個較爲複雜的08到14的升級並搭建高可用的工做,真正的實戰項目和本身搭建的測試系統仍是有很大的差異。項目整個工期持續了3個月，因此本文只是簡單的說明思路和步驟，另外介紹了幾個常見的大坑。項目中的主要步驟，我的認爲這也是在數據庫高可用方案搭建過程當中的必要步驟：

1. 系統背景調查
2. 業務調研，生成第一版方案
3. 詳細調研，對象整理
4. 測試環境搭建
5. 系統測試，肯定方案
6. 上線演練，肯定時間窗口
7. 壓力測試
8. 正式上線
9. 上線後監控
10. 解決問題，制定維護方案

 

 　　此項目能夠說是比較嚴格的遵循了相關管理的標準，在三個月的實施中，咱們秉承這「穩定大於效率」的思想，工做細化到每一步，每一步都有詳細的說明，最終保證了三套系統的上線運行零故障！

　　

 文章用到的 Expert FOR SQLSERVER 工具下載連接：http://zhuancloud.com/ReceptionViews/Install.html

 ----------------------------------------------------------------------------------------------------

注：此文章爲原創，歡迎轉載，請在文章頁面明顯位置給出此文連接！
若您以爲這篇文章還不錯請點擊下右下角的推薦，很是感謝！