故障转移后,可用性组数据库处于“正在恢复”状态的时间过长

Bah*_*ban 5 sql-server availability-groups

架构: \n我在多子网故障转移群集上运行 2 节点同步提交 AlwaysOn 配置。主节点位于欧洲,辅助节点位于美国。我的可用性组中只有一个数据库,即 SCOM 的 OperationsManager db。

\n\n
    \n
  • 主要主机和辅助主机相同。
  • \n
  • 两个机器上的 SQL Server 版本:13.0.5237 和 Windows Core
  • \n
  • 更新:我将两台服务器都修补到 10.0.5270.0 ,但没有帮助。
  • \n
  • DB VLF 计数仅为 27。
  • \n
\n\n

问题: \n当我启动故障转移时,数据库在几秒钟内成功从主节点故障转移到辅助节点。然而,新的辅助(旧的主)数据库进入恢复/恢复阶段并在那里停留大约 30 分钟。我在故障恢复到原始主数据库时也经历了同样的事情,所以这是一个双向发生的问题。

\n\n

调查结果: \n我在互联网上搜索了此问题并阅读了文档来调查该问题。当从主数据库到辅助数据库的角色更改完成后,新的辅助数据库将经历 3 个阶段:

\n\n

同步状态: \xe2\x80\x9c 未同步\xe2\x80\x9d ;数据库状态:在线

\n\n

同步状态: \xe2\x80\x9c 未同步\xe2\x80\x9d ;数据库状态:正在恢复

\n\n

同步状态: \xe2\x80\x9cREVERTING\xe2\x80\x9d ;数据库状态:正在恢复

\n\n

就我而言,所有时间都花在最后一步上。我还通过查看性能计数器“ SQLServer:数据库副本日志剩余用于撤消”来监视撤消过程

\n\n

我在故障转移测试之前检查了主站点,以发现任何长时间运行的事务或打开的事务,但找不到。故障转移后,“用于撤消的剩余日志”约为 30MB,辅助数据库需要 30 分钟才能返回“已同步”状态。考虑到我们在同步提交模式下运行并且主数据库上的工作负载很小,恕我直言,重做阶段不应花费 30 分钟。

\n\n

SQL Server 错误日志:我发现了这个奇怪的消息。

\n\n
    \n
  • 于 2019 年 2 月 22 日下午 2:55 在 LSN (2558:107841:1) 的数据库“OperationsManager”中启动的事务“RECEIVE MSG”(ID 0x000000004d52c65a 0001:01c4e415)的远程强化失败。

  • \n
  • 于 2019 年 2 月 22 日下午 2:59 在 LSN (2558:107843:46) 的数据库“OperationsManager”中启动的事务“GhostCleanupTask”(ID 0x000000004d6d15aa 0001:01c4eaa0)的远程强化失败。

  • \n
\n\n

故障转移开始:\n在此输入图像描述

\n\n

在此输入图像描述

\n\n

故障转移结束:\n在此输入图像描述

\n\n

总而言之

\n\n

您以前见过这个问题吗?您有什么建议吗?

\n

Jos*_*ell 3

每当数据库恢复运行时间较长时,无论是正常恢复还是 AG 故障转移,需要检查的一件事是 VLF 计数。拥有大量 VLF(数千或数万)或异常大小的 VLF(一到两个极大的 VLF)将导致此过程变得缓慢如爬行。

\n\n

在有问题的数据库上运行以下命令:

\n\n
USE YourDatabaseName;\nGO\n\nDBCC LOGINFO;\n
Run Code Online (Sandbox Code Playgroud)\n\n

注意:如果您使用的是 SQL Server 2016 SP2 或更高版本,则可以使用此动态管理功能而不是 DBCC 命令:sys.dm_db_log_info

\n\n

返回的行数就是您拥有的 VLF 数。如果该数字非常大,或者该FileSize列显示 VLF 中的极端异常值,那么您可以通过(在较高级别上)解决缓慢恢复问题:

\n\n
    \n
  1. 将日志文件缩小到尽可能小
  2. \n
  3. 将其恢复到目标大小
  4. \n
  5. 确保根据您的典型日志增长率和事务日志备份频率将自动增长设置为合理的数字
  6. \n
\n\n

修复 VLF 大小问题的详细信息已在其他地方广泛介绍,这里是一个示例:A Busy/Accidental DBA\xe2\x80\x99s Guide toManaging VLFs

\n