最近幫客戶實施的基于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.rzrgm.cn/lyhabc/p/3828496.html
第四步：打開AlwaysOn的顯示面板，查看成都機房節點數據同步情況，如果已經追上主庫的日志那么實施故障轉移
第五步：手動進行故障轉移
第六步：在成都機房節點查看AlwaysOn的轉移情況
第七步：在成都機房節點使用腳本驗證當前數據庫中各個表的記錄數是否與手動故障轉移之前的記錄數相同，腳本地址：http://www.rzrgm.cn/lyhabc/p/3828496.html
第八步：在成都機房節點打開AlwaysOn的AG的屬性界面，將所有的輔助副本都改為異步提交模式
第九步：拆除10樓到成都的VPN
第十步：重慶機房所有數據庫服務器關閉SQL服務然后關機
第十一步：所有服務器搬到15樓并開機
第十二步：重建15樓到成都的VPN
第十三步：在成都機房節點kill掉所有數據庫連接并設置程序用數據庫帳號設置為禁用，禁止連接數據庫
第十四步：在成都機房節點打開AlwaysOn的AG的屬性界面，將原來重慶機房的主副本節點改為同步提交模式
第十五步：使用腳本查看當前數據庫中各個表的記錄數，腳本地址：http://www.rzrgm.cn/lyhabc/p/3828496.html
第十六步：打開AlwaysOn的顯示面板，查看重慶機房節點數據同步情況，如果已經追上主庫的日志那么實施故障轉移
第十七步：手動進行故障轉移
第十八步：在重慶機房節點查看AlwaysOn的轉移情況
第十九步：在重慶機房節點使用腳本驗證當前數據庫中各個表的記錄數是否與手動故障轉移之前的記錄數相同，腳本地址：http://www.rzrgm.cn/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異地，對異地節點數據庫做完整備份

然后拷貝到備份服務器或磁帶庫，這樣就可以保存比較長時間的數據庫備份，即使開發要找回半年甚至一年之前的那個數據也是可以的

 

SQL Review：代碼審核，收集數據庫性能數據，排查性能問題，盡可能減少對主庫的影響

 

最后這次項目的整個切換過程還有很多細節，就不寫在文章里了，有興趣的朋友可以發站短跟我交流^_^

 

 

參考文章

http://www.tech-coffee.net/understand-failover-cluster-quorum/

http://windowsitpro.com/windows-server-2012/dynamic-quorum-windows-server-2012

 

附上AlwaysOn搭建教程
第一篇
http://www.rzrgm.cn/lyhabc/p/4678330.html
第二篇
http://www.rzrgm.cn/lyhabc/p/4682028.html
第三篇
http://www.rzrgm.cn/lyhabc/p/4682986.html
第四篇
http://www.rzrgm.cn/lyhabc/p/6136227.html

 

 

本文版權歸作者所有，未經作者同意不得轉載。