說到高可用，看官們會想到很多方案，也許是自親身經(jīng)歷過系統(tǒng)從單機變成高可用的痛苦過程，也許有的看官只是在自己的虛機上搭建過測試的玩具。今天本篇用我自己的真實經(jīng)歷給大家講述，不管怎么樣實戰(zhàn)和測試玩耍還是很大的區(qū)別的！可能你覺得搭建一套高可用方案很簡單，配置配置就OK了，但在真正的復雜系統(tǒng)中一切就沒有那么輕松了！
文章主要講述升級并搭建AlwaysOn高可用的過程，以實施的思路為主。文中并沒有搭建集群的步驟，搭建步驟請自行學習(個人認為會搭建可用組并不是關鍵，而一系列的調(diào)研細節(jié)才是項目成功的關鍵)。
背景
客戶的現(xiàn)有方案是一套使用發(fā)布訂閱構建的讀寫分離方案，總體來說系統(tǒng)構建的很不錯。也是在SQL2012之前很常見的一套架構。
架構圖如下：
客戶的需求：SQL server 2008 R2 升級到SQL SERVER 2014 使用AlwaysOn 替換現(xiàn)有發(fā)布訂閱架構。實現(xiàn)本地高可用、讀寫分離，異地災備等，并應用部分2014的新功能，如內(nèi)存優(yōu)化表等提升系統(tǒng)性能和并發(fā)能力等。
前期調(diào)研
數(shù)據(jù)收集
前期對系統(tǒng)的了解很重要！那么怎么樣對系統(tǒng)有一個初步直觀并且詳細的了解呢？用腳本收集？這是時候就體現(xiàn)出工具的專業(yè)和協(xié)作價值。工欲善其事，必先利其器！
確定方案
通過前期的需求分析，并對客戶系統(tǒng)結構有了一個初步的了解后，我們用了將近一周的時間從架構的復雜度，易用性，客戶程序改動程度，性能，穩(wěn)定性等多個角度敲定了最終的方案。
架構圖如下：
從原來那么復雜的架構變成如此清爽的架構，使用AlwaysOn取代復雜的發(fā)布訂閱，使用AlwaysOn的只讀節(jié)點實現(xiàn)讀寫分離，另外使用異地災備節(jié)點取代原有的異地發(fā)布數(shù)據(jù)庫，很不錯吧！這也是用戶最傾向的架構，因為復雜度低，相對穩(wěn)定易于維護。這里要注意！凡事有利必有弊！要說“但是”了。
但是，升級改動的成本大大提升！
為什么這么說？我們接著看！
詳細調(diào)研
這樣的一個復雜的系統(tǒng)前期的詳細調(diào)研是需要很長時間的，幾套系統(tǒng)不僅僅是架構上設計的比較復雜，功能應用、接口等更是復雜！下面是主要的一些梳理過程：
原有系統(tǒng)結構
我們首先要對原有系統(tǒng)的設計有透徹的了解，客戶在兩地分別有一個數(shù)據(jù)中心，三套系統(tǒng)有大量的業(yè)務要使用其他系統(tǒng)的數(shù)據(jù)，所以這里使用發(fā)布訂閱準時時的把其他系統(tǒng)中的數(shù)據(jù)發(fā)布到系統(tǒng)中的一個數(shù)據(jù)庫，并使用同義詞指向訂閱來的數(shù)據(jù)。這種結構降低了使用鏈接服務器跨實例甚至跨機房訪問的性能消耗！并且多份數(shù)據(jù)訂閱到多個只讀的節(jié)點，從而實現(xiàn)了報表、接口等業(yè)務的讀寫分離。
系統(tǒng)對象整理
因為要做升級遷移，所以對象的整理是很重要的工作，業(yè)務對象的遺漏可能會帶來不可挽回的災難！甚至可能會導致整個升級，架構部署的回滾！幾套系統(tǒng)中涉及的對象列表過于龐大，比如帳號幾十個，幾十個作業(yè)，上百個同義詞，實例級觸發(fā)器等等…..
服務器劃分：
- 主庫對象
- 讀寫分離各個只讀庫對象
- 發(fā)布到其他業(yè)務系統(tǒng)的數(shù)據(jù)服務器配置對象
- 其他應用程序?qū)ο?/li>
對象劃分：
- 數(shù)據(jù)庫帳號
- 鏈接服務器
- 實例級觸發(fā)器
- 作業(yè)
- 系統(tǒng)參數(shù)
- 維護計劃
- cdc
- BI相關
- 同義詞
- 程序集
- 郵件
- 操作員
- 只讀庫多出來的索引、視圖等對象
- 等等等
測試過程
搭建測試環(huán)境
所有的升級、高可用項目測試環(huán)節(jié)都是必不可少的。首先是測方案配合業(yè)務的可行性，因為作為第三方公司不能對用戶所有的應用關系，系統(tǒng)架構了如指掌，甚至客戶方自己的工程師可能也做不到這一點。其次是測試功能在新環(huán)境下是否出現(xiàn)異常。還有就是對收集并遷移的系統(tǒng)對象進行一次查缺補漏。這樣也可以盡量保證系統(tǒng)上線時發(fā)生故障的概率！
測試環(huán)境無疑是任何升級、架構變更的必要步驟，也只有經(jīng)過充分的測試才能做到心中有數(shù)，進而實現(xiàn)零故障上線。
上線演練
上線演練？這是個什么東西？
首先數(shù)據(jù)庫的操作一定要確定可實施的時間窗口！保證在固定的時間窗口完成工作很重要，那么這就是上線演練的最大好處，我們使用準備出的新機器完全模擬上線的全部步驟，并記錄每個步驟使用的時間，可能出現(xiàn)的風險，最遲的完成時間等等。其次搭建完成后我們可以用這個環(huán)境（就是完成后正式環(huán)境的配置）進行壓力測試。
上線演練是一個很必要的步驟，但這個步驟要視實際的情況而定，比如升級的方式，環(huán)境的配置等。在這樣的一個項目中我們做了兩輪的上線演練！
實施過程
制定性能基線
這樣一個大的變動，數(shù)據(jù)庫在各個階段的性能指標是什么樣子的呢？ 這里我們依然使用 Expert for SQL Server 工具對每一個階段實施前后性能進行對比，這樣不僅能對實施的影響進行監(jiān)控，更能清晰地分析出每個實施階段對性能的影響！
對每個指標也都做相應的對比分析，指標比較多這里不一一介紹了，請參見優(yōu)化系列文章：
SQL SERVER全面優(yōu)化——-Expert for SQL Server 診斷系列
性能優(yōu)化
這里的性能優(yōu)化，我們主要針對語句系統(tǒng)的一些常規(guī)參數(shù)、慢語句進行第一輪的優(yōu)化！另外一個重點就是為了應對升級到2014后可能變慢的語句進行調(diào)整！具體什么樣的語句可能變慢？ 這個…
- 系統(tǒng)的重點語句（執(zhí)行最頻繁的）
- 語句復雜的
- 大面積測試
這里為什么要在升級前就作這樣的優(yōu)化工作而不是升級后系統(tǒng)運行時在針對慢的語句進行分析呢？ 這個道理很簡單，如果上線了才發(fā)現(xiàn)如果變慢的功能很多，或變慢的是頻繁的功能那么上線的效果就是倆個字”失敗”。雖然有的看官知道可以使用提示或降低兼容級別解決這個問題，但是這只是特殊場景下的極端手段，而并不是解決的根本。所以建議如果你有升級到2014的需要，那么這樣的優(yōu)化手段一定要提前做！
升級到2014
升級數(shù)據(jù)庫完全可以寫成好幾篇博客，甚至寫本小書都可以了！這里只做簡單介紹，和一些要重點注意的問題！
升級方式
升級方式有2種：in place 和side by side，這里采用的是side by side！ 通俗地說就是準備新的服務器，安裝對應版本的數(shù)據(jù)庫，然后把數(shù)據(jù)還原上去。side by side的好處就是升級不會影響原有的環(huán)境，即使失敗也能修改程序指向回退到原環(huán)境！
升級2014 最大的一個問題
2014 的新特性 “參數(shù)估計” ！這個讓人興奮又苦惱的新功能會導致很多語句在升級到2014 后變慢，因為前面的優(yōu)化階段已經(jīng)對這部分重點關注了，所以這部分的問題基本已經(jīng)消滅！但是萬惡的分區(qū)表（200多個分區(qū)）依然導致了批處理的性能嚴重問題！
集群搭建
集群搭建可能沒有過多的可說支出，正常創(chuàng)建故障轉移集群，搭建AlwaysOn等，但這其中的細節(jié)還是很多的，比如仲裁的方式？異地節(jié)點的虛擬IP設置？節(jié)點個數(shù)與業(yè)務的配合？等等等的問題，這里也就不一一細說了。
整體步驟中充斥著無數(shù)的細節(jié)，每一個細節(jié)可能都決定著方案的可行性，升級、架構變更的成敗。限于篇幅這里只舉幾個可能常見的問題說明一下！
- CDC功能與AlwaysOn：官方文檔上說CDC與AlwaysOn可以實現(xiàn)轉移后CDC不間斷，但是經(jīng)過測試CDC作業(yè)在AlwaysOn切換后多次執(zhí)行失敗則不會再一次自動運行，CDC的logreader和發(fā)布訂閱時一樣的，但在沒有發(fā)布訂閱存在的情況下只有CDC作業(yè)會出現(xiàn)上述問題。解決辦法：配置調(diào)控作業(yè)（節(jié)點切換作業(yè)控制）
- 重建索引操作：由于配置異地節(jié)點。日志重建變成問題，測試中重建索引的日志量是單機下日志量的好幾倍！這樣會導致異地日志隊列過長。解決辦法：使用手工腳本拆分細化索引重建，根據(jù)隊列大小和傳輸速率控制每天的日志量。
- 2014下語句變慢：具體就不細說了，2014參數(shù)估計和200+分區(qū)表組合產(chǎn)生的語句變慢問題至今沒有答案。目前只是使用一些方法避免了這個問題！（這個問題也請遇到的朋友給些思路，謝謝）
- 只讀副本上有寫操作：由于一些報表操作使用中間臨時表，這里臨時表不是#temp 這種而是真正的物理表作為臨時表。解決方案：修改為臨時表，或創(chuàng)建單獨數(shù)據(jù)庫（不在可用性組中），在使用同義詞指向新庫實現(xiàn)寫操作。
遇到的問題真的是各種多，這也是為什么說當你的常規(guī)技術手段都掌握的時候，踩過的坑就是你的成長了！
總結 ： 文章只是簡單分享了一個較為復雜的08到14的升級并搭建高可用的工作，真正的實戰(zhàn)項目和自己搭建的測試系統(tǒng)還是有很大的差別。項目整個工期持續(xù)了3個月，所以本文只是簡單的說明思路和步驟，另外介紹了幾個常見的大坑。項目中的主要步驟，個人認為這也是在數(shù)據(jù)庫高可用方案搭建過程中的必要步驟：
1系統(tǒng)背景調(diào)查
2業(yè)務調(diào)研，生成初版方案
3詳細調(diào)研，對象整理
4測試環(huán)境搭建
5系統(tǒng)測試，確定方案
6上線演練，確定時間窗口
7壓力測試
8正式上線
9上線后監(jiān)控
10解決問題，制定維護方案
此項目可以說是比較嚴格的遵循了相關管理的標準，在三個月的實施中，我們秉承這“穩(wěn)定大于效率”的思想，工作細化到每一步，每一步都有詳細的說明，最終保證了三套系統(tǒng)的上線運行零故障！
核心關注：拓步ERP系統(tǒng)平臺是覆蓋了眾多的業(yè)務領域、行業(yè)應用，蘊涵了豐富的ERP管理思想，集成了ERP軟件業(yè)務管理理念，功能涉及供應鏈、成本、制造、CRM、HR等眾多業(yè)務領域的管理，全面涵蓋了企業(yè)關注ERP管理系統(tǒng)的核心領域，是眾多中小企業(yè)信息化建設首選的ERP管理軟件信賴品牌。
轉載請注明出處：拓步ERP資訊網(wǎng)http://m.hanmeixuan.com/
本文標題：數(shù)據(jù)庫高可用實戰(zhàn)案例——-架構優(yōu)化
本文網(wǎng)址：http://m.hanmeixuan.com/html/support/11121520057.html
相關文章
