說到高可用,看官們會想到很多方案,也許是自親身經歷過系統從單機變成高可用的痛苦過程,也許有的看官只是在自己的虛機上搭建過測試的玩具。今天本篇用我自己的真實經歷給大家講述，不管怎么樣實戰和測試玩耍還是很大的區別的！可能你覺得搭建一套高可用方案很簡單，配置配置就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個月，所以本文只是簡單的說明思路和步驟，另外介紹了幾個常見的大坑。項目中的主要步驟，個人認為這也是在數據庫高可用方案搭建過程中的必要步驟：
- 系統背景調查
- 業務調研，生成初版方案
- 詳細調研，對象整理
- 測試環境搭建
- 系統測試，確定方案
- 上線演練，確定時間窗口
- 壓力測試
- 正式上線
- 上線后監控
- 解決問題，制定維護方案
此項目可以說是比較嚴格的遵循了相關管理的標准，在三個月的實施中，我們秉承這“穩定大於效率”的思想，工作細化到每一步，每一步都有詳細的說明，最終保證了三套系統的上線運行零故障！
文章用到的 Expert FOR SQLSERVER 工具下載鏈接：http://zhuancloud.com/ReceptionViews/Install.html
----------------------------------------------------------------------------------------------------
注：此文章為原創，歡迎轉載，請在文章頁面明顯位置給出此文鏈接！
若您覺得這篇文章還不錯請點擊下右下角的推薦，非常感謝！