這是上周遇到的一個案例：對已有的硬件進行升級而引發的問題，期間還觸發了一個比較嚴重的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組也變成正在解析的情況
從下圖中，AG組中只能識別到當前節點；
但Node_B仍可以正常的訪問（讀寫正常，listener ip也可以正常使用），而Node_C則無法訪問；這種狀態極為不合理；
此外，在errorlog中，發現大量remote harden of transaction的報錯
執行備份(spid=509)被checkpoint進程阻塞(spid=23)，又被DB STARTUP進程阻塞(spid=35)
根據微軟工程的分析“這是最近剛剛發現的一個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住
無奈，只能重啟服務器。但神奇的是，重啟大法在這里居然是最完美的解決方案。重啟后，各種服務均恢復正常；
總結：這個案例比較特殊，在切換過程中遇到了另一個BUG，但好在BUG中出現的內部進程的死鎖通過重啟得到了釋放。另外，對于第一部分提到的misaligned的問題，最好在安裝硬件后，先檢查一下物理扇區的大小是否一致，以免出現性能問題；
新聞熱點
疑難解答
