前段时间我们生产环境有台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，需要打个补丁。但是我觉得没那么简单，后面继续跟微软那边沟通。