今天是大年初三，先跟大家拜個年，祝大家新年快樂。
今天處理了一個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啟動賬戶用的是一個單獨的、專用的賬戶就不會有這個問題，其實我們也建議這樣的賬戶要盡量與業務賬戶分開，避免互相影響。