資料庫高可用實戰案例：架構優化
說到高可用,看官們會想到很多方案,也許是自親身經歷過系統從單機變成高可用的痛苦過程,也許有的看官只是在自己的虛機上搭建過測試的玩具。今天本篇用我自己的真實經歷給大家講述，不管怎麼樣實戰和測試玩耍還是很大的區別的！可能你覺得搭建一套高可用方案很簡單，配置配置就OK了，但在真正的複雜系統中一切就沒有那麼輕鬆了！
文章主要講述升級並搭建AlwaysOn高可用的過程，以實施的思路為主。文中並沒有搭建叢集的步驟，搭建步驟請自行學習。
背景
客戶的現有方案是一套使用釋出訂閱構建的讀寫分離方案，總體來說系統構建的很不錯。也是在SQL2012之前很常見的一套架構。
架構圖如下：
客戶的需求：SQL server 2008 R2 升級到SQL SERVER 2014 使用AlwaysOn 替換現有釋出訂閱架構。實現本地高可用、讀寫分離，異地災備等，並應用部分2014的新功能，如記憶體優化表等提升系統性能和併發能力等。
前期調研
資料收集
前期對系統的瞭解很重要！那麼怎麼樣對系統有一個初步直觀並且詳細的瞭解呢？用指令碼收集？這是時候就體現出工具的專業和協作價值。工欲善其事，必先利其器！
確定方案
通過前期的需求分析，並對客戶系統結構有了一個初步的瞭解後，我們用了將近一週的時間從架構的複雜度，易用性，客戶程式改動程度，效能，穩定性等多個角度敲定了最終的方案。
架構圖如下：
從原來那麼複雜的架構變成如此清爽的架構，使用AlwaysOn取代複雜的釋出訂閱，使用AlwaysOn的只讀節點實現讀寫分離，另外使用異地災備節點取代原有的異地釋出資料庫，很不錯吧！這也是使用者最傾向的架構，因為複雜度低，相對穩定易於維護。這裡要注意！凡事有利必有弊！要說“但是”了。
但是，升級改動的成本大大提升！
為什麼這麼說？我們接著看！
詳細調研
這樣的一個複雜的系統前期的詳細調研是需要很長時間的，幾套系統不僅僅是架構上設計的比較複雜，功能應用、介面等更是複雜！下面是主要的一些梳理過程：
原有系統結構
我們首先要對原有系統的設計有透徹的瞭解，客戶在兩地分別有一個數據中心，三套系統有大量的業務要使用其他系統的資料，所以這裡使用釋出訂閱準時時的把其他系統中的資料釋出到系統中的一個數據庫，並使用同義詞指向訂閱來的資料。這種結構降低了使用連結伺服器跨例項甚至跨機房訪問的效能消耗！並且多份資料訂閱到多個只讀的節點，從而實現了報表、介面等業務的讀寫分離。
系統物件整理
因為要做升級遷移，所以物件的整理是很重要的工作，業務物件的遺漏可能會帶來不可挽回的災難！甚至可能會導致整個升級，架構部署的回滾！幾套系統中涉及的物件列表過於龐大，比如帳號幾十個，幾十個作業，上百個同義詞，例項級觸發器等等…..
伺服器劃分：
- 主庫物件
- 讀寫分離各個只讀庫物件
- 釋出到其他業務系統的資料伺服器配置物件
- 其他應用程式物件
物件劃分：
- 資料庫帳號
- 連結伺服器
- 例項級觸發器
- 作業
- 系統引數
- 維護計劃
- cdc
- BI相關
- 同義詞
- 程式集
- 郵件
- 操作員
- 只讀庫多出來的索引、檢視等物件
- 等等等
測試過程
搭建測試環境
所有的升級、高可用專案測試環節都是必不可少的。首先是測方案配合業務的可行性，因為作為第三方公司不能對使用者所有的應用關係，系統架構瞭如指掌，甚至客戶方自己的工程師可能也做不到這一點。其次是測試功能在新環境下是否出現異常。還有就是對收集並遷移的系統物件進行一次查缺補漏。這樣也可以儘量保證系統上線時發生故障的概率！
測試環境無疑是任何升級、架構變更的必要步驟，也只有經過充分的測試才能做到心中有數，進而實現零故障上線。
上線演練
上線演練？這是個什麼東西？
首先資料庫的操作一定要確定可實施的時間視窗！保證在固定的時間視窗完成工作很重要，那麼這就是上線演練的最大好處，我們使用準備出的新機器完全模擬上線的全部步驟，並記錄每個步驟使用的時間，可能出現的風險，最遲的完成時間等等。其次搭建完成後我們可以用這個環境（就是完成後正式環境的配置）進行壓力測試。
上線演練是一個很必要的步驟，但這個步驟要視實際的情況而定，比如升級的方式，環境的配置等。在這樣的一個專案中我們做了兩輪的上線演練！
實施過程
制定效能基線
這樣一個大的變動，資料庫在各個階段的效能指標是什麼樣子的呢? 這裡我們依然使用 Expert for SQL Server 工具對每一個階段實施前後效能進行對比，這樣不僅能對實施的影響進行監控，更能清晰地分析出每個實施階段對效能的影響！
對每個指標也都做相應的對比分析，指標比較多這裡不一一介紹了，請參見優化系列文章：
效能優化
這裡的效能優化，我們主要針對語句系統的一些常規引數、慢語句進行第一輪的優化！另外一個重點就是為了應對升級到2014後可能變慢的語句進行調整！具體什麼樣的語句可能變慢？ 這個…
- 系統的重點語句（執行最頻繁的）
- 語句複雜的
- 大面積測試吧…..哈哈哈
這裡為什麼要在升級前就作這樣的優化工作而不是升級後系統執行時在針對慢的語句進行分析呢? 這個道理很簡單,如果上線了才發現如果變慢的功能很多,或變慢的是頻繁的功能那麼上線的效果就是倆個字”失敗”。雖然有的看官知道可以使用t提示或降低相容級別解決這個問題，但是這只是特殊場景下的極端手段，而並不是解決的根本。所以建議如果你有升級到2014的需要，那麼這樣的優化手段一定要提前做！
升級到2014
升級資料庫完全可以寫成好幾篇部落格，甚至寫本小書都可以了！這裡只做簡單介紹，和一些要重點注意的問題！
升級方式
升級方式有2種：in place 和side by side，這裡採用的是side by side！ 通俗地說就是準備新的伺服器，安裝對應版本的資料庫，然後把資料還原上去。side by side的好處就是升級不會影響原有的環境，即使失敗也能修改程式指向回退到原環境！
升級2014 最大的一個問題
2014 的新特性 “引數估計” ！這個讓人興奮又苦惱的新功能會導致很多語句在升級到2014 後變慢，因為前面的優化階段已經對這部分重點關注了，所以這部分的問題基本已經消滅！但是萬惡的分割槽表（200多個分割槽）依然導致了批處理的效能嚴重問題！
叢集搭建
叢集搭建可能沒有過多的可說支出，正常建立故障轉移叢集，搭建AlwaysOn等，但這其中的細節還是很多的，比如仲裁的方式？異地節點的虛擬IP設定？節點個數與業務的配合？等等等的問題，這裡也就不一一細說了。
程式修改
這個架構的修改也必然導致程式上的變化，這也是前文中提到的為什麼客戶最傾向的架構，因為複雜度低而使成本大大提升。原始系統中的關聯性無法通過釋出訂閱實現本地化訪問，又不能使用效能非常差的連結伺服器。那麼路只有一條，那就是修改程式訪問方式，簡單理解為在程式中分別在各自的資料庫中查出相應的資料，然後通過程式在記憶體中操作處理。
細節問題處理
總體的實施步驟可以說就是這樣了，但是在這個整體步驟中充斥著無數的細節，每一個細節可能都決定著方案的可行性，升級、架構變更的成敗。限於篇幅這裡只舉幾個可能常見的問題說明一下！
- CDC功能與AlwaysOn：官方文件上說CDC與AlwaysOn可以實現轉移後CDC不間斷，但是經過測試CDC作業在AlwaysOn切換後多次執行失敗則不會再一次自動執行，CDC的logreader和釋出訂閱時一樣的，但在沒有釋出訂閱存在的情況下只有CDC作業會出現上述問題。解決辦法：配置調控作業（切點切換作業控制）
- 重建索引操作：由於配置異地節點。日誌重建變成問題，測試中重建索引的日誌量是單機下日誌量的好幾倍！這樣會導致異地日誌佇列過長。解決辦法：使用手工指令碼拆分細化索引重建，根據佇列大小和傳輸速率控制每天的日誌量。
- 2014下語句變慢：具體就不細說了，2014引數估計和200+分割槽表組合產生的語句變慢問題至今沒有答案。目前只是使用一些方法避免了這個問題！（這個問題也請遇到的朋友給些思路，謝謝）
- 只讀副本上有寫操作：由於一些報表操作使用中間臨時表，這裡臨時表不是#temp 這種而是真正的物理表作為臨時表。解決方案：修改為臨時表，或建立單獨資料庫（不在可用性組中），在使用同義詞指向新庫實現寫操作。
遇到的問題真的是各種多，這也是為什麼說當你的常規技術手段都掌握的時候，踩過的坑就是你的成長了！
總結 ： 文章只是簡單分享了一個較為複雜的08到14的升級並搭建高可用的工作,真正的實戰專案和自己搭建的測試系統還是有很大的差別。專案整個工期持續了3個月，所以本文只是簡單的說明思路和步驟，另外介紹了幾個常見的大坑。專案中的主要步驟，個人認為這也是在資料庫高可用方案搭建過程中的必要步驟：
- 系統背景調查
- 業務調研，生成初版方案
- 詳細調研，物件整理
- 測試環境搭建
- 系統測試，確定方案
- 上線演練，確定時間視窗
- 壓力測試
- 正式上線
- 上線後監控
- 解決問題，制定維護方案
此專案可以說是比較嚴格的遵循了相關管理的標準，在三個月的實施中，我們秉承這“穩定大於效率”的思想，工作細化到每一步，每一步都有詳細的說明，最終保證了三套系統的上線執行零故障！