分布式可用性组直接播种失败，失败状态 SQL 错误，失败状态 2

Question

我们刚刚开始设置分布式可用性组，以将我们的生产数据库复制到新的报告集群中。我们为复制设置的第一个可用性组运行良好，没有任何问题，但是当我们转移到具有更大数据库（总共超过 3TB）的第二个可用性组时，它花费的时间更长，并且 5 个数据库中有两个失败了。我们将分布式可用性组设置为使用直接播种，并在查询 sys.dm_hadr_automatic_seding 表时将 current_state 指示为 FAILED，故障状态为 2（SQL 错误）或 21（播种检查消息超时）：

我们可以做些什么来解决这个问题？

Answer 1

AlwaysOn Professional 博客提供了一些直接播种的常规故障排除步骤，还包括有关跟踪标志 9567 的一些详细信息，以在播种期间启用压缩，但我没有找到有关 SQL 错误或播种超时的任何详细信息。

我们之前遇到过大型数据库的问题，导致可用性组出现问题，但这通常可以通过将主数据库中的最新事务日志应用于副本来解决。

在这种情况下，数据库在辅助可用性组中列为正在恢复，因此我尝试应用主数据库中的最新事务日志备份，然后将数据库加入到辅助可用性组中：

--Restore transaction logs from primary and stay in recovery mode. Multiple backup files may need to be restored from oldest to newest.
RESTORE LOG stackoverflow from disk = '\\Backups\SQL\_Trans\StackOverflow_AG\StackOverflow\StackOverflow_LOG_20170810_175400.trn' WITH NORECOVERY;

ALTER DATABASE stackoverflow SET HADR AVAILABILITY GROUP = [StackOverflow_RAG];
ALTER DATABASE stackoverflow SET HADR RESUME;

这适用于两个失败的数据库并修复了复制问题。现在，我们的报告集群的所有数据库都与主要可用性组保持同步：