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