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

我们已经准备好在SQL Server上执行大型升级，并注意到我正在尝试解决的Distributed Availability Groups的一些异常行为，然后再进行下一步。

上个月，我将远程辅助服务器从SQL Server 2016升级到SQL Server2017。该服务器是多个分布式可用性组（DAG）和单独的可用性组（AG）的一部分。升级该服务器时，我们没有意识到它会进入无法读取的状态，因此在过去的一个月中，我们仅依赖主服务器。

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

但是，小学的故事却截然不同。据报道

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

最初出现恐慌之后，我尝试了以下操作以使DAG中的内容再次同步：

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

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

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

我同时检查了SQL Server错误日志和辅助服务器上的事件查看器，没有发现异常。

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

但是，小学的故事却截然不同。据报道，单独的AG正在同步，没有任何问题，但DAG处于“不同步/不正常”状态

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

不幸的是，由于问题已解决，因此很难确切说明问题所在……但是如果将来发生这种情况的人：

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

如果您正在该辅助数据库上接收数据，但分布式ag仍显示未同步或运行状况不佳，那么我将让它花点时间查看DMV值是否发生变化，因为它显然是在接收和处理日志块。

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

我将以所有我没有生产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 STARTUP节点才能恢复（SPID是处理重做操作的源）。我建议您事先查看阻塞的SPID，以尝试确定原因（通常是长期运行的报告）。

如果您想更多相关信息，有一个伟大的文章（包括监控这类使用XES行为的）在这里。

检查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远一点。

您的分布式可用性组（DAG）是否在不同区域之间划分？如果是这样，您可能会遭受默认的SESSION_TIMEOUT值（10秒）太低的困扰。这意味着两个区域之间的等待时间太长，无法可靠地完成同步。

普通可用性组可以增加其SESSION_TIMEOUT值，以使同步会话更加稳定。去年年底，我注意到DAG的SESSION_TIMEOUT参数无法编辑。这意味着DAG仅适用于低延迟情况。我们与Microsoft记录了一张票，并于今年早些时候发布了修补程序。

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