最近幫客戶實施的基於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的屬性介面，將成都異地節點改為同步提交模式
第三步：使用指令碼檢視當前資料庫中各個表的記錄數，指令碼地址：http://www.cnblogs.com/lyhabc/p/3828496.html
第四步：開啟AlwaysOn的顯示皮膚，檢視成都機房節點資料同步情況，如果已經追上主庫的日誌那麼實施故障轉移
第五步：手動進行故障轉移
第六步：在成都機房節點檢視AlwaysOn的轉移情況
第七步：在成都機房節點使用指令碼驗證當前資料庫中各個表的記錄數是否與手動故障轉移之前的記錄數相同，指令碼地址：http://www.cnblogs.com/lyhabc/p/3828496.html
第八步：在成都機房節點開啟AlwaysOn的AG的屬性介面，將所有的輔助副本都改為非同步提交模式
第九步：拆除10樓到成都的VPN
第十步：重慶機房所有資料庫伺服器關閉SQL服務然後關機
第十一步：所有伺服器搬到15樓並開機
第十二步：重建15樓到成都的VPN
第十三步：在成都機房節點kill掉所有資料庫連線並設定程式用資料庫帳號設定為禁用，禁止連線資料庫
第十四步：在成都機房節點開啟AlwaysOn的AG的屬性介面，將原來重慶機房的主副本節點改為同步提交模式
第十五步：使用指令碼檢視當前資料庫中各個表的記錄數，指令碼地址：http://www.cnblogs.com/lyhabc/p/3828496.html
第十六步：開啟AlwaysOn的顯示皮膚，檢視重慶機房節點資料同步情況，如果已經追上主庫的日誌那麼實施故障轉移
第十七步：手動進行故障轉移
第十八步：在重慶機房節點檢視AlwaysOn的轉移情況
第十九步：在重慶機房節點使用指令碼驗證當前資料庫中各個表的記錄數是否與手動故障轉移之前的記錄數相同，指令碼地址：http://www.cnblogs.com/lyhabc/p/3828496.html
第二十步：在重慶機房節點開啟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/