主页 / dba / 问题 / 200269
Accepted
Taryn
Asked: 2018-03-15 09:12:43 +0800 CST

服务器重新启动后 SQL Server 分布式可用性组数据库不同步

  • 772

我们正准备在我们的 SQL Server 上执行大规模升级，并注意到分布式可用性组的一些异常行为，我试图在继续之前解决这些行为。

上个月，我将远程辅助服务器从 SQL Server 2016 升级到 SQL Server 2017。该服务器是多个分布式可用性组 (DAG)和单独的可用性组 (AG)的一部分。当我们升级这台服务器时，我们并没有意识到它会进入一个不可读的状态，所以在过去的一个月里，我们一直只依赖于主服务器。

作为即将进行的升级的一部分，我将CU 4补丁应用到服务器并重新启动它。当服务器重新上线时，刚刚修补的辅助服务器显示所有 DAG/AG 正在同步，没有任何问题。

然而，初选展示了一个非常不同的故事。据报道

  • 单独的 AG 正在同步，没有任何问题
  • 但 DAG 处于不同步/不健康状态

在最初惊慌失措之后，我尝试了以下操作以使 DAG 中的事物再次同步：

  • 从主节点开始，我停止并恢复了数据移动。这没有开始同步数据。
  • 在第二个（我刚刚修补的那个）上我运行了ALTER DATABASE [<database] SET HADR RESUME;- 它执行没有错误，但没有恢复任何同步

我最后一次尝试再次同步数据是登录到辅助服务器，然后手动重新启动 SQL Server 服务。手动重新启动服务似乎有点极端，因为我希望重新启动服务器就足够了。

有没有人遇到过重启后 DAG 没有开始同步到辅助服务器的问题？如果是这样，它是如何解决的？

我检查了 SQL Server 错误日志和辅助服务器上的事件查看器，我看不到任何异常。

sql-server availability-groups

3 个回答

  1. Best Answer

    请注意，这不是一个确定的答案，但它是与Taryn聊天后的最佳答案。

    然而，初选展示了一个非常不同的故事。它报告说单独的 AG 正在同步，没有任何问题，但 DAG 处于未同步/不健康状态

    如果分布式 ag 底层的各个数据库和 AG 表示它们运行良好且正在同步，那么这很可能只是 DMV 和/或 SSMS 仪表板中的一个小问题。由于错误日志中没有任何内容表明副本未连接或处于断开状态。

    不幸的是，由于问题已经解决，很难确切地说出它是什么......但是将来如果有人发生这种情况：

    • 检查所有集群上的sys.dm_hadr_database_replica_states以寻找任何不健康的东西。如果一切正常，则可能 DMV 尚未更新
    • 如果不正常，请检查错误日志/DMV 是否存在连接问题（例如无法连接到转发器/全局主节点）
    • 丹的回答提到了数据库启动可能出现的问题 - 尽管在这种情况下无法读取实例，因此很可能不是问题，但可能是您的情况
    • 如果数据库是可读的，则使用虚拟表/插入进行冒烟测试或...
    • 使用 DEBUG 通道项目的扩展事件会话sqlserver.hadr_dump_log_block或sqlserver.hadr_apply_log_block查看辅助节点是否实际接收/应用日志块或...
    • 性能对象SQLServer:Database Replica\Log Bytes Received/sec

    如果您在该辅助服务器上接收数据，但分布式 ag 仍然显示不同步或不健康，那么我会让它稍微看看 DMV 值是否发生变化，因为它显然正在接收和处理日志块。

    但是，如果不是，那么我们将需要进一步调查这超出了答案的范围。

    • 9

  2. 我将在所有这一切的开头声明我没有任何 DAG 在生产中。从根本上说，这条建议应该适用于 AG 和 DAG。

    服务重启后同步是否恢复？如果是这样，那么我对原因的最佳猜测将是阻塞重做 SPID。如果即使在重新启动后仍然没有同步，这就是我首先要检查的内容：

    阻塞 AG 重做 SPID

    通常只会发生在可读的二级上。要检查，请运行以下命令：

    select session_id, blocking_session_id, db_name(database_id), wait_type
from sys.dm_exec_requests
where command = 'DB STARTUP'

    如果出现任何阻塞 SPID，则需要在辅助服务器恢复之前将其杀死（DB STARTUPSPID 是处理重做操作的对象）。我建议事先查看阻塞 SPID 以尝试确定原因（通常是长期运行的报告）。

    如果您想进一步了解这方面的信息，这里有一篇很棒的文章（包括使用 XE 监控此类行为）。

    检查 DMV

    如果数据移动被暂停，您可以参考 DMV 以获取有关暂停原因的更多信息。运行以下命令：

    select db_name(database_id), synchronization_state_desc, database_state_desc, suspend_reason_desc
from sys.dm_hadr_database_replica_states

    BOL 文章进一步描述了suspend_reason 。

    • 4

  3. 您的分布式可用性组 (DAG) 是否在不同区域之间拆分？如果是这样，您可能会遇到默认 SESSION_TIMEOUT 值（10 秒）太低的问题。这意味着两个区域之间的延迟太高而无法可靠地完成同步。

    正常可用性组可以增加其 SESSION_TIMEOUT 值以使同步会话更加稳定。去年年底我注意到 DAG 的 SESSION_TIMEOUT 参数无法编辑。这意味着 DAG 仅适用于低延迟场景。我们向微软登记了一张票，今年早些时候发布了一个修补程序。

    改进：为 SQL Server 2016 和 2017 中的分布式可用性组副本配置 SESSION_TIMEOUT 值

    • 0

相关问题