數(shù)據(jù)庫高可用實戰(zhàn)案例——-架構(gòu)優(yōu)化

數(shù)據(jù)庫高可用架構(gòu)優(yōu)化大數(shù)據(jù)

Double_K | 2016-09-06 11:50

【數(shù)據(jù)猿導讀】說到高可用,看官們會想到很多方案,也許是自親身經(jīng)歷過系統(tǒng)從單機變成高可用的痛苦過程,也許有的看官只是在自己的虛機上搭建過測試的玩具。今天本篇用我自己的真實經(jīng)歷給大家講述，不管怎么樣實戰(zhàn)和測試玩耍還是很大的區(qū)別的

數(shù)據(jù)庫高可用實戰(zhàn)案例——-架構(gòu)優(yōu)化

可能你覺得搭建一套高可用方案很簡單，配置配置就OK了，但在真正的復雜系統(tǒng)中一切就沒有那么輕松了！

文章主要講述升級并搭建AlwaysOn高可用的過程，以實施的思路為主。文中并沒有搭建集群的步驟，搭建步驟請自行學習(個人認為會搭建可用組并不是關(guān)鍵,而一系列的調(diào)研細節(jié)才是項目成功的關(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)。實現(xiàn)本地高可用、讀寫分離，異地災備等，并應用部分2014的新功能，如內(nèi)存優(yōu)化表等提升系統(tǒng)性能和并發(fā)能力等。

前期調(diào)研

數(shù)據(jù)收集

前期對系統(tǒng)的了解很重要！那么怎么樣對系統(tǒng)有一個初步直觀并且詳細的了解呢？用腳本收集？這是時候就體現(xiàn)出工具的專業(yè)和協(xié)作價值。工欲善其事，必先利其器！

確定方案

通過前期的需求分析，并對客戶系統(tǒng)結(jié)構(gòu)有了一個初步的了解后，我們用了將近一周的時間從架構(gòu)的復雜度，易用性，客戶程序改動程度，性能，穩(wěn)定性等多個角度敲定了最終的方案。

架構(gòu)圖如下：

從原來那么復雜的架構(gòu)變成如此清爽的架構(gòu)，使用AlwaysOn取代復雜的發(fā)布訂閱，使用AlwaysOn的只讀節(jié)點實現(xiàn)讀寫分離，另外使用異地災備節(jié)點取代原有的異地發(fā)布數(shù)據(jù)庫，很不錯吧！這也是用戶最傾向的架構(gòu)，因為復雜度低，相對穩(wěn)定易于維護。這里要注意！凡事有利必有弊！要說“但是”了。

但是，升級改動的成本大大提升！

為什么這么說？我們接著看！

詳細調(diào)研

這樣的一個復雜的系統(tǒng)前期的詳細調(diào)研是需要很長時間的，幾套系統(tǒng)不僅僅是架構(gòu)上設計的比較復雜，功能應用、接口等更是復雜！下面是主要的一些梳理過程：

原有系統(tǒng)結(jié)構(gòu)

我們首先要對原有系統(tǒng)的設計有透徹的了解，客戶在兩地分別有一個數(shù)據(jù)中心，三套系統(tǒng)有大量的業(yè)務要使用其他系統(tǒng)的數(shù)據(jù)，所以這里使用發(fā)布訂閱準時時的把其他系統(tǒng)中的數(shù)據(jù)發(fā)布到系統(tǒng)中的一個數(shù)據(jù)庫，并使用同義詞指向訂閱來的數(shù)據(jù)。這種結(jié)構(gòu)降低了使用鏈接服務器跨實例甚至跨機房訪問的性能消耗！并且多份數(shù)據(jù)訂閱到多個只讀的節(jié)點，從而實現(xiàn)了報表、接口等業(yè)務的讀寫分離。

系統(tǒng)對象整理

因為要做升級遷移，所以對象的整理是很重要的工作，業(yè)務對象的遺漏可能會帶來不可挽回的災難！甚至可能會導致整個升級，架構(gòu)部署的回滾！幾套系統(tǒng)中涉及的對象列表過于龐大，比如帳號幾十個，幾十個作業(yè)，上百個同義詞，實例級觸發(fā)器等等…..

服務器劃分：

主庫對象

讀寫分離各個只讀庫對象

發(fā)布到其他業(yè)務系統(tǒng)的數(shù)據(jù)服務器配置對象

其他應用程序?qū)ο?/p>

對象劃分：

數(shù)據(jù)庫帳號

鏈接服務器

實例級觸發(fā)器

作業(yè)

系統(tǒng)參數(shù)

維護計劃

cdc

BI相關(guān)

同義詞

程序集

郵件

操作員

只讀庫多出來的索引、視圖等對象

等等等

測試過程

搭建測試環(huán)境

所有的升級、高可用項目測試環(huán)節(jié)都是必不可少的。首先是測方案配合業(yè)務的可行性，因為作為第三方公司不能對用戶所有的應用關(guān)系，系統(tǒng)架構(gòu)了如指掌，甚至客戶方自己的工程師可能也做不到這一點。其次是測試功能在新環(huán)境下是否出現(xiàn)異常。還有就是對收集并遷移的系統(tǒng)對象進行一次查缺補漏。這樣也可以盡量保證系統(tǒng)上線時發(fā)生故障的概率！

測試環(huán)境無疑是任何升級、架構(gòu)變更的必要步驟，也只有經(jīng)過充分的測試才能做到心中有數(shù)，進而實現(xiàn)零故障上線。

上線演練

上線演練？這是個什么東西？

首先數(shù)據(jù)庫的操作一定要確定可實施的時間窗口！保證在固定的時間窗口完成工作很重要，那么這就是上線演練的最大好處，我們使用準備出的新機器完全模擬上線的全部步驟，并記錄每個步驟使用的時間，可能出現(xiàn)的風險，最遲的完成時間等等。其次搭建完成后我們可以用這個環(huán)境（就是完成后正式環(huán)境的配置）進行壓力測試。

上線演練是一個很必要的步驟，但這個步驟要視實際的情況而定，比如升級的方式，環(huán)境的配置等。在這樣的一個項目中我們做了兩輪的上線演練！

實施過程

制定性能基線

這樣一個大的變動，數(shù)據(jù)庫在各個階段的性能指標是什么樣子的呢? 這里我們依然使用 Expert for SQL Server 工具對每一個階段實施前后性能進行對比，這樣不僅能對實施的影響進行監(jiān)控，更能清晰地分析出每個實施階段對性能的影響！

數(shù)據(jù)庫

對每個指標也都做相應的對比分析，指標比較多這里不一一介紹了，請參見優(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)對這部分重點關(guān)注了，所以這部分的問題基本已經(jīng)消滅！但是萬惡的分區(qū)表（200多個分區(qū)）依然導致了批處理的性能嚴重問題！

集群搭建

集群搭建可能沒有過多的可說支出，正常創(chuàng)建故障轉(zhuǎn)移集群，搭建AlwaysOn等，但這其中的細節(jié)還是很多的，比如仲裁的方式？異地節(jié)點的虛擬IP設置？節(jié)點個數(shù)與業(yè)務的配合？等等等的問題，這里也就不一一細說了。

整體步驟中充斥著無數(shù)的細節(jié)，每一個細節(jié)可能都決定著方案的可行性，升級、架構(gòu)變更的成敗。限于篇幅這里只舉幾個可能常見的問題說明一下！

CDC功能與AlwaysOn：官方文檔上說CDC與AlwaysOn可以實現(xiàn)轉(zhuǎ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ī)技術(shù)手段都掌握的時候，踩過的坑就是你的成長了！

總結(jié) ：文章只是簡單分享了一個較為復雜的08到14的升級并搭建高可用的工作,真正的實戰(zhàn)項目和自己搭建的測試系統(tǒng)還是有很大的差別。項目整個工期持續(xù)了3個月，所以本文只是簡單的說明思路和步驟，另外介紹了幾個常見的大坑。項目中的主要步驟，個人認為這也是在數(shù)據(jù)庫高可用方案搭建過程中的必要步驟：