SQLSERVER 2012之AlwaysOn -- 一次硬件升級引發的問題


這是上周遇到的一個案例:對已有的硬件進行升級而引發的問題,期間還觸發了一個比較嚴重的BUG,可謂多災多難;不過值得慶幸的是,在一連串連鎖問題出現的時候,並沒有出現人工操作失誤(這往往是在處理故障中風險最高、影響最大的問題)而擴大故障影響范圍;

 

==========================華麗麗的分割線==========================

    先說一下環境:

    我做的是跨機房3節點alwayson:

    部署方面:3個節點中,兩個位於主機房,同步模式,另外一個位於異地機房,跨子網異步模式;

    軟件方面:windows 2012+SQLSERVER 2012 SP2+CU3;

    硬件方面:由於該系統上線時間較早,除了本地硬盤(RAID 10)用於存放必要的安裝程序包外,每個節點各配置了一塊IO卡用於存放數據、日志文件以及備份

 

    此前該系統在使用時,應用側經常出現提交事務抖動(本地機房兩節點同步),改為異步模式后應用側性能表現良好;我們知道,在同步模式下,由於應用端需要等待在同步secondary節點完成日志固化(harden)后才能收到提交或回滾信息,因此兩節點間的網絡環境,以及磁盤IO能力就成為上述影響的關鍵;

    而在此之前,我們已經對網絡進行了優化(詳見:《SQLServer 2012之AlwaysOn —— 指定數據同步鏈路,消除網絡抖動導致的提交延遲問題》),因此可以排除網絡影響;另外,我們通過對磁盤IO性能的監控(尤其是checkpoint時的影響),最終定位到磁盤IO確實存在壓力,最后決定更換IO卡;

    在申請設備的時候,我們發現,由於此前的IO卡為第一代產品,與目前最新采購的第三代產品有兼容性問題(無法同時安裝),因此需要先將secondary節點從alwayson環境中踢出,重新安裝后重新初始化數據,並添加回alwayson環境;這一步按照標准步驟執行,十分順利;

    其次,我們准備切換AG到已更新硬件的節點(此處我們叫他Node_B),結果發現切換過程很順利(手動故障轉移),但切換后不能進行備份(由於后續需要將另外一個節點進行同樣的更新硬件操作,不能備份就意味着在重新加回alwayson環境時,不能初始化數據),隨即又將服務切回Node_A上(最初的master節點);

    隨后,我們檢查了Node_B的errorlog,發現其中出現如下錯誤信息:

Information 29-Apr-2014 3:17:24 PM MSSQL$PRD 9012 Server There have been 25958400 misaligned log IOs which required falling back to synchronous IO. The current IO is on file W:\MOUNTLOG\PRDLOG\PRDLOG1.ldf. 
Information 29-Apr-2014 3:17:17 PM MSSQL$PRD 9012 Server There have been 25958144 misaligned log IOs which required falling back to synchronous IO. The current IO is on file W:\MOUNTLOG\PRDLOG\PRDLOG1.ldf.

    其實從Node_B更換完硬件,並添加回alwayson環境后,就一直再報類似的錯誤,只是切換比較順利,我們都忽略了檢查errorlog這一關鍵的步驟;

    繼續來說上面的錯誤信息,misaligned是個針對於IO方向的報警,具體的原理可以參考以下文章

http://blogs.msdn.com/b/saponsqlserver/archive/2014/10/02/message-misaligned-log-ios-which-required-falling-back-to-synchronous-io-in-sql-server-error-log.aspx

    而導致misaligned的原因,是由於兩個節點的IO卡,其物理扇區大小不一致(Node_A為512,Node_B為4096;此處的物理扇區是存儲設備底層設置的,與操作系統中format 4K~64K不是一個概念,操作系統格式化的定義是分配單元大小,或稱之為簇)。上述鏈接中對9012錯誤進行了詳細的分析,再此不再贅述;

    另一方面,是由於misaligned而導致了切換節點后無法進行備份么?第二天,我又搭了一套類似的環境進行測試,但問題沒有重現;於是我們准備用另一套方案進行升級:

    既然由於AG中兩個節點的物理扇區大小不等導致misaligned,我們准備先在現有AG中再增加一個物理扇區大小為4096的節點(Node_C),然后再切換AG到Node_B后,踢掉Node_A。這樣AG中有兩個同步關系的節點(Node_A、Node_C,且物理扇區大小均為4096),或許可以實現備份。

 

==========================華麗麗的分割線==========================

    按照上述方案,我們又安排了一次停機。但這次在切換服務並踢掉Node_A后,不但備份問題沒有解決,連AG組也變成正在解析的情況

image

 

 

 

    從下圖中,AG組中只能識別到當前節點;

image

   

 

 

 

 

 

 

    但Node_B仍可以正常的訪問(讀寫正常,listener IP也可以正常使用),而Node_C則無法訪問;這種狀態極為不合理;

    此外,在errorlog中,發現大量remote harden of transaction的報錯

image

   

 

 

 

 

 

 

      執行備份(spid=509)被checkpoint進程阻塞(spid=23),又被DB STARTUP進程阻塞(spid=35)image

 

 

 

image

 

 

 

 

 

 

 

image

 

 

 

 

 

 

 

image

 

 

 

 

 

 

 

    根據微軟工程的分析“這是最近剛剛發現的一個SQL 的bug,只發生在SP2 CU3和CU4上面。即便不做BACKUP,也會發生這樣的阻塞。”

    這可能是由於SQL Server內部發生了死鎖,建議盡快再所有節點上安裝以下這個補丁。

    http://support.microsoft.com/en-us/kb/3033492

    http://support.microsoft.com/en-us/kb/3034679

    您可以單獨安裝hotfix,或者安裝SQL 2012 SP2CU5,我們建議您對於所有打過SP2 CU3(5556)和CU4(5569)並且配有AlwaysOn的環境,都盡快打上CU5

    http://support.microsoft.com/en-us/kb/3037255/en-us

 

    但目前的情況是需要先保證alwayson恢復正常,於是我們准備通過停機復制數據文件的方式將數據庫遷移到其他alwayson環境下;但在停止sqlserver服務的時候hang住

image

 

 

 

 

 

 

 

    無奈,只能重啟服務器。但神奇的是,重啟大法在這里居然是最完美的解決方案。重啟后,各種服務均恢復正常;

image

 

 

 

 

 

 

 

總結:這個案例比較特殊,在切換過程中遇到了另一個BUG,但好在BUG中出現的內部進程的死鎖通過重啟得到了釋放。另外,對於第一部分提到的misaligned的問題,最好在安裝硬件后,先檢查一下物理扇區的大小是否一致,以免出現性能問題;


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM