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