前段時間我們生產環境有台alwayson高可用副本掛了，一開始是發現數據庫賬號不能登錄，以為是密碼過期，登錄到副本上面發現數據庫同步中斷。
這個時候肯定第一時間是先查下SQL SERVER日志看下是什么報錯原因引起的。
然后在SQL SERVER日志里面找到凌晨2點15分30秒的時候目標數據庫有一條錯誤日志，提示Always On Availability Groups data movement for database 'xxxx' has been suspended for the following reason: "system" (Source ID 2; Source string: 'SUSPEND_FROM_REDO'). To resume data movement on the database, you will need to resume the database manually. ，緊接着的一條日志 During redoing of a logged operation in database 'XXXX' (page (1:9) if any), an error occurred at log record ID (372842:430056:1). Typically, the specific failure is previously logged as an error in the operating system error log. Restore the database from a full backup, or repair the database.
第一條日志提示日志redo中斷，第二條日志直接指出哪條日志的redo失敗。
也就是SQL SERVER卡着這條log的redo上面，所以數據庫進入Not Synchronizing狀態。
后面我們是按照常規的做法，ALTER DATABASE XXX SET HADR RESUME嘗試恢復數據庫。
這是常規微軟推薦的做法，讓數據庫嘗試自然恢復。
但是執行完命令后，第一時間打開windows 事件查看器查看下MSSQLSERVER日志提示，還是提示無法redo (372842:430056:1)。也就是SET HADR RESUME沒辦法恢復數據庫。
其實這個問題發生過不止一次，這算是第三次了吧。后來我們咨詢了微軟（我們的服務器是Azure雲，SQL SERVER是RDS版），微軟的工程師讓我們把SQL SERVER服務重啟就行。
兩次都是重啟SQL SERVER解決問題，只是日志redo的時間會比較久。
重啟SQL SERVER后刷新一下SQL SERVER 日志，看到有提示數據庫在恢復中。
隨后提示恢復完成
然后注意通過監控腳本觀察副本的同步狀態以及剩余redo日志，只要有變化，剩余redo日志在減少，就說明恢復成功。
---------------------------------------------------------------------------
上面說了這不是第一次遇到副本同步失敗，巧的是，上次同步失敗也是凌晨2點的時候，同樣是周六，這個時間點剛好我們數據庫完整備份的作業時間。為此我還特地去翻了7/30和5/21上兩次失敗的日志記錄。
三次發生的問題幾乎都是一樣，某條log無法redo。有趣的時候，我發現每次錯誤發生之前都會有一條日志：Parallel redo is shutdown for database 'XXXX' with worker pool size [8].
之前有篇隨筆寫過，這台Azure服務器使用了VM災備備份方案PlateSpin相關的技術，會導致完整備份的LSN中斷。SQL Server ->> 數據庫差異備份提示3035錯誤，需要先對數據庫執行完整備份。
現在是隔三差五的出現日志無法在高可用副本上面redo，導致同步失敗。
截止10月27號，我收到微軟Azure的工程師那邊的回應是這個是個sql server的bug，需要打個補丁。但是我覺得沒那么簡單，后面繼續跟微軟那邊溝通。