最近幫客戶實施的基於SQL Server AlwaysOn跨機房切換項目 最近一個來自重慶的客戶找到走起君,客戶的業務是做移動互聯網支付,是微信支付收單渠道合作伙伴,資料庫里存儲的是支付流水和交易流水。 由於客戶那邊沒有DBA,所以找到走起君商量一個資料庫伺服器搬遷項目。 項目背景 客戶需要把在10 ...
最近幫客戶實施的基於SQL Server AlwaysOn跨機房切換項目
最近一個來自重慶的客戶找到走起君,客戶的業務是做移動互聯網支付,是微信支付收單渠道合作伙伴,資料庫里存儲的是支付流水和交易流水。
由於客戶那邊沒有DBA,所以找到走起君商量一個資料庫伺服器搬遷項目。
項目背景
客戶需要把在10樓的伺服器全部搬到15樓,而且需要在有限的停機時間之內,客戶使用的資料庫是SQL Server2008R2,Windows2008R2
客戶的兩個重要要求
1、總停機時間少於10分鐘
2、數據不能有任何丟失
出方案
針對這兩個要求,SQL Server有哪些可以選擇的方案呢?
方案一 複製
使用複製,當前客戶環境已經有一套資料庫複製在跑,10樓的發佈庫不動,在15樓增加一個訂閱庫,數據複製到15樓,但是複製有一個致命點:不保證數據一致性,因為複製是非同步的
複製只能滿足要求一,不能滿足要求二,只能拋棄這個方案
方案二 日誌備份
在15樓增加一臺資料庫伺服器,10樓的發佈庫做完整備份還原到15樓的資料庫,然後在搬遷的時候追加一個日誌備份,並還原到15樓的資料庫伺服器
日誌備份保存的數據是完整備份到日誌備份這個時間段的數據,由於每天寫入的變更數據量比較大,導致ldf文件也比較大,達到40G+,在測試過程中
發現,kill掉資料庫所有連接-》設置資料庫為只讀模式-》備份-》移動日誌備份文件-》還原日誌備份文件-》設置資料庫為讀寫模式 ,整個過程花費時間超過15分鐘
只能滿足要求二,不能滿足要求一,並且一旦遷移過程出錯,回滾時間+遷移時間>要求的停機時間
回滾:一旦15樓的資料庫有數據寫入,要回滾需要完整備份資料庫或分離資料庫然後還原到10樓或附加到10樓的資料庫,回滾時間無法滿足小於10分鐘的要求
方案三 AlwaysOn
跟客戶商量溝通之後,最終選定SQL Server的AlwaysOn
從示意圖可以看出,目前的架構需要做如何升級
增加一個成都機房
所有資料庫升級到SQL Server2014 SP2
所有操作系統升級到Windows2012R2
回滾:一旦15樓的資料庫有數據寫入,要回滾可以先kill掉資料庫所有連接,禁用資料庫帳號不讓連接資料庫,等成都從庫同步完數據之後,重新手動故障轉移回去成都機房
整個回滾過程10分鐘之內可以搞定
然後嗶哩吧啦嗶哩吧啦過了一個月,客戶說軟體和硬體環境都已經準備好了,當中資料庫升級過程走起君也有參與在內
升級完畢之後的環境
操作系統:Windows2012R2
資料庫:SQL Server2014 SP2
兩邊機房帶寬:各10M 沒有拉專線
VPN:使用華為防火牆內置的VPN功能
資料庫大小:100G+
AlwaysOn節點數:5個 重慶機房3個 成都機房2個
升級之後的示意圖
到目前為止,大家可能已經猜到走起君做了這個架構之後要怎麼做了
由於是點對點VPN,所以切換過程涉及拆除VPN和重建VPN的過程
切換過程
(1)主庫切換到成都機房
(2)拆除10樓到成都機房的VPN
(3)10樓所有伺服器關機搬到15樓
(4)15樓所有伺服器開機
(5)重建15樓到成都的VPN,建好VPN之後,成都機房的主庫和域控會自動與重慶機房的域控和從庫通信,主庫會把差異數據發回重慶,無須人工介入
(6)成都機房主庫切換回去重慶機房15樓
這裡有一個比較嚴重的問題
客戶沒有使用專線,兩邊機房只有10M帶寬!
客戶沒有使用專線,兩邊機房只有10M帶寬!
客戶沒有使用專線,兩邊機房只有10M帶寬!
重要的問題說三遍!
這樣一個低成本的架構,沒有專線,帶寬不高,只用硬體防火牆的VPN搭建起來的內網,SQL Server可以做得到嗎???
答案是:沒問題,SQL Server完全做得到!!!
這裡軟體環境需要滿足下麵要求
1、操作系統必須是Windows2012R2或以上版本
2、資料庫必須是SQL Server2012或以上版本
再次用文字描述一下切換過程
第一步:kill掉所有資料庫連接並設置程式用資料庫帳號設置為禁用,禁止連接資料庫
第二步:打開AlwaysOn的AG的屬性界面,將成都異地節點改為同步提交模式
第三步:打開AlwaysOn的顯示面板,查看成都機房節點數據同步情況,如果已經追上主庫的日誌那麼實施故障轉移
第四步:手動進行故障轉移
第五步:在成都機房節點查看AlwaysOn的轉移情況
第六步:在成都機房節點打開AlwaysOn的AG的屬性界面,將所有的輔助副本都改為非同步提交模式
第七步:拆除10樓到成都的VPN
第八步:重慶機房所有資料庫伺服器關閉SQL服務然後關機
第九步:所有伺服器搬到15樓並開機
第十步:重建15樓到成都的VPN
第十一步:在成都機房節點打開AlwaysOn的AG的屬性界面,將原來重慶機房的主副本節點改為同步提交模式
第十二步:打開AlwaysOn的顯示面板,查看重慶機房節點數據同步情況,如果已經追上主庫的日誌那麼實施故障轉移
第十三步:手動進行故障轉移
第十四步:在重慶機房節點查看AlwaysOn的轉移情況
第十五步:在重慶機房節點打開AlwaysOn的AG的屬性界面,將成都節點副本改為非同步提交模式
整個過程非常順利,沒有數據丟失,停機時間控制在10分鐘之內
原理
相信不少人都用過SQL Server的AlwaysOn集群,AlwaysOn集群真的是非常方便,隨意切換
數據做了加密和壓縮 ,資料庫塊級別的傳輸
數據自動補償
切換和回切不需要重建集群
操作傻瓜化
數據0丟失
重慶機房關機時間段數據自動補償,避免數據丟失
兩個停機時間點,每個時間點大約5分鐘
時間點1
時間點2
最後一個,之所以要使用Windows2012R2操作系統,是因為Windows2012R2引入了動態仲裁機制,也就是說當前WSFC集群只有一個節點的情況下
整個WSFC集群也會不會掛掉
利用這個機制,當重慶機房所有伺服器關機的情況下,成都機房的資料庫節點依然能working,這個相比Windows2008R2是一個相當大的進步
這裡有一個註意點
在Windows2008R2時代,因為沒有動態仲裁機制,所以需要將異地節點的投票權去掉,這裡有幾個原因
1、當異地節點掛掉之後,整個WSFC集群節點湊不夠基數,導致整個WSFC集群失去仲裁掛掉
2、主庫無故切換到異地節點(設置為手動故障轉移防止這種情況發生)
3、SQL2012異地節點無故變為正在解析狀態(重啟異地節點資料庫伺服器的SQL Server服務解決這個問題,現在SQL2014 SP2沒出現過這個問題)
而到了Windows2012R2時代,有些老司機依然會繼續使用這種做法,把異地節點的投票權去掉,這樣做的話,當前整個WSFC集群沒有一個節點擁有投票的情況下整個WSFC集群就會掛掉,成都機房的AG就會顯示“正在解析”,這是因為當前整個WSFC集群裡面沒有一個節點擁有投票權,即使成都這個節點在開機狀態,所以提醒一下大家,如果操作系統是Windows2012R2,不需要把異地節點投票權去掉,因為到目前為止,在上面的三種情況下,第二和第三種情況通過方法可以解決,第一種情況因為Windows2012R2引入了動態仲裁機制也不會發生
如上圖,在只有成都節點的情況下,整個WSFC也不會掛掉
總結
到目前為止,走起君發現身邊使用SQL Server的朋友大多只在本地機房部署AlwaysOn,而沒有部署AlwaysOn異地節點
只在本地機房部署AlwaysOn是不利於應對風險的,做AlwaysOn異地容災其實還有很多好處
使用場景
機房斷網斷電:之前有一個新聞《脈脈失聯的15個小時》,聯通凈網行動把機房斷網了,如果做了AlwaysOn異地節點那麼可以把主庫先切換到別的機房,應用也一併切換過去
那麼就可以規避這種風險了
http://mt.sohu.com/20160730/n461773714.shtml
BI:BI抽取大量數據會影響線上的網路穩定性,部署AlwaysOn異地節點,BI從異地節點抽取業務數據,可以減少對業務的影響
資料庫備份集中保存:因為線上伺服器的磁碟容量一般都很有限,一般只保留幾天或者一個星期的資料庫備份,部署AlwaysOn異地,對異地節點資料庫做完整備份
然後拷貝到備份伺服器或磁帶庫,這樣就可以保存比較長時間的資料庫備份,即使開發要找回半年甚至一年之前的那個數據也是可以的
最後這次項目的整個切換過程還有很多細節,就不寫在文章里了,有興趣的朋友可以發站短跟我交流^_^
參考文章:http://www.tech-coffee.net/understand-failover-cluster-quorum/
如有不對的地方,歡迎大家拍磚o(∩_∩)o
本文版權歸作者所有,未經作者同意不得轉載。