积极答复者
alway on辅助节点备份日志失败

问题
-
已以用户 domain\administrator 的身份执行。 已为数据库 'K3DBConfiger2020343517986',文件 'SqlServer_MC_20120727193627_Log' (位于文件 1 上)处理了 2253 页。 [SQLSTATE 01000] (消息 4035) BACKUP LOG 成功处理了 2253 页,花费 0.078 秒(225.610 MB/秒)。 [SQLSTATE 01000] (消息 3014) 已为数据库 'test',文件 'SqlServer_BC_20120727194252_Log' (位于文件 1 上)处理了 3767747 页。 [SQLSTATE 01000] (消息 4035) 辅助副本上数据库“test”的日志备份失败,因为无法在主数据库上提交新的备份信息。请在承载当前主副本的服务器实例的 SQL Server 错误日志中查看数据库状态。如果主数据库正在参与该可用性组,请重试该操作。 [SQLSTATE 42000] (错误 35296) BACKUP LOG 正在异常终止。 [SQLSTATE 42000] (错误 3013). 该步骤失败。
我在主节点上找到以下日志信息:
源 spid40s
消息
Error: 35250, Severity: 16, State: 13.
源 spid40s
消息
The connection to the primary replica is not active. The command cannot be processed.源 spid40s
消息
Error: 35250, Severity: 16, State: 13.源 spid40s
消息
The connection to the primary replica is not active. The command cannot be processed.源 spid86
消息
Autogrow of file 'SqlServer_BC_20120727194252_Log' in database 'test' took 101263 milliseconds. Consider using ALTER DATABASE to set a smaller FILEGROWTH for this file.后面这些日志不知道是否相关:
源 spid59
消息
Autogrow of file 'SqlServer_BC_20120727194252_Log' in database 'test' took 108931 milliseconds. Consider using ALTER DATABASE to set a smaller FILEGROWTH for this file.源 spid72
消息
Autogrow of file 'SqlServer_BC_20120727194252_Log' in database 'test' took 120244 milliseconds. Consider using ALTER DATABASE to set a smaller FILEGROWTH for this file.源 spid13s
消息
FlushCache: cleaned up 20348 bufs with 2521 writes in 121199 ms (avoided 7392 new dirty bufs) for db 8:0源 spid13s
消息
average writes per second: 20.80 writes/sec
average throughput: 1.30 MB/sec, I/O saturation: 1050, context switches 2195源 spid13s
消息
last target outstanding: 4200, avgWriteLatency 0
因为这个任务是每两小时执行一次,基本上每天都会有相同报错,等我看到报错手动执行任务时又成功了。- 已编辑 forsylvanas 2020年10月7日 8:50 update
答案
全部回复
-
你好,
请问SQL Server版本。
另外您的备份作业是使用维护计划创建的吗
""SQL Server related"" forum will be migrated to a new home on Microsoft Q&A SQL Server!
We invite you to post new questions in the "SQL Server related" forum’s new home on Microsoft Q&A SQL Server !
For more information, please refer to the sticky post. -
你好,
既然调用了sys.fn_hadr_backup_is_preferred_replica 函数,那么请问此AG的Backup Preferences和Backup Replica Priorities设置。
尝试在备份作业中不调用此函数,直接在辅助副本上进行备份,是否有问题。
如果是两个节点的可用性组,不如直接调用 sys.fn_hadr_is_primary_replica来判断是否是辅助副本。
- 已编辑 Cris ZhanMicrosoft contingent staff 2020年10月8日 9:15
-
我觉得和函数没多大区别,我只有两个节点;备份首选项是首选辅助副本,优先级相同都是50;
在这种情况下sys.fn_hadr_backup_is_preferred_replica 和sys.fn_hadr_is_primary_replica应该是没什么区别的,always on辅助副本就是首选备份副本;
另外我觉得和调用函数关系也不大,我前端挂的是IIS应用,有客户端反馈会出现卡顿情况(根据客户端观察1-2分钟左右就自动恢复正常了),我推测卡顿时always on组是异常的,但我在故障转移群集中没找到错误日志,只有在数据库日志中找到上面的一些相关信息;
当我收到客户端卡顿的反馈时最直观的感受就是数据库节点实例可以通过SSMS正常连接但展开数据库时十分缓慢,如果我收到数据库报警邮件再去查看时因为时效性问题等我查看时,always on组已经是正常的了,我再次手动执行备份任务它就不报错了,所以到现在为止也没找到很好的方法去排查....
-
你好,
每次自动执行备份作业都会失败并报错吗?
注意到错误日志中的另一个关于日志文件增长的消息,此日志文件似乎持续增长。日志自动增长的时间是否能对应客户端卡顿的时间。
""SQL Server related"" forum will be migrated to a new home on Microsoft Q&A SQL Server!
We invite you to post new questions in the "SQL Server related" forum’s new home on Microsoft Q&A SQL Server !
For more information, please refer to the sticky post. -
已以用户 domain\administrator 的身份执行。 已为数据库 Configer',文件 'SqlServer_MC__Log' (位于文件 1 上)处理了 597 页。 [SQLSTATE 01000] (消息 4035) BACKUP LOG 成功处理了 597 页,花费 0.056 秒(83.217 MB/秒)。 [SQLSTATE 01000] (消息 3014) 已为数据库 'CLOUD',文件 'SqlServer_BC_20120727194252_Log' (位于文件 1 上)处理了 730144 页。 [SQLSTATE 01000] (消息 4035) BACKUP LOG 成功处理了 730144 页,花费 17.952 秒(317.749 MB/秒)。 [SQLSTATE 01000] (消息 3014). 该步骤成功。
频率改为15分钟每次,每次备份共耗时19秒左右,这吞吐量正常吗?
另外频繁的备份截断日志对数据库有什么影响吗?