今天是大年初三，先跟大家拜個年，祝大家新年快樂。
今天處理了一個alwaysOn問題——輔助副本因為磁盤空間不足一直顯示【未同步——可疑】，在日志中可以看到數據庫處于掛起狀態，與主副本失去同步。原以為只需把輔助副本的磁盤做個清理，騰出一點空間，然后重啟SQL Server服務就好了（重啟讓數據庫從掛起狀態進入到聯機狀態，然后讓alwaysOn重新開始同步）。
但，重啟失敗！！！
在操作系統日志中看到SQL Server啟動失敗的原因是：（啟動賬戶的）用戶名和密碼錯誤！！！
當初做alwaysOn的時候圖方便，直接用了一個域管理員的用戶名和密碼，后來因為安全策略的緣故，這個賬戶的密碼被重新改過了，當時沒人記得同步修改SQL Server的啟動賬戶密碼。放在平常，只要SQL Server不重啟，密碼沒有改也沒事，但重啟后，就必須使用正確的密碼了。否則會出現這個錯誤。
所以要解決這個問題只需修改為正確的密碼。
即使如此，alwaysOn還是不會立即恢復同步，從數據庫日志中可以看到，另一個不幸的事情發生了：
Database Mirroring login attempt failed with error: ‘Connection handshake failed. An OS call failed(8009030c))x8009030c(登錄沒有成功)。state.67’. [client:10.1.2.2]
10.1.2.2是alwaysOn主副本的IP，從報錯信息來看，是主副本的數據庫鏡像端點（AlwaysOn使用數據庫鏡像的端點進行通訊）無法登錄到輔助副本上。
這是一個賬戶登錄的問題。剛剛我們修改了輔助副本的登錄賬戶密碼，但沒有修改主副本的，主副本還是用的失效的密碼來訪問輔助副本的鏡像端點，輔助副本自然會拒絕這個連接請求，所以我們還需（在非業務時段）修改下主副本登錄賬戶的密碼，然后重啟SQL Server就可以了。
數據庫鏡像端點重新建立連接后，這個錯誤就不會再有了，但此時alwaysOn還是不會恢復同步，還需要在輔助副本上的可用數據庫上右擊選擇“恢復數據移動”，自此alwaysOn才開始恢復同步。
這個問題其實是可以避免的，如果當時SQL Server啟動賬戶用的是一個單獨的、專用的賬戶就不會有這個問題，其實我們也建議這樣的賬戶要盡量與業務賬戶分開，避免相互影響。
文章列表
留言列表
