今天早上，在对两个新表进行常规数据库部署后，我注意到事务复制已停止 3 个多小时。当复制恢复时，它又在 3 个多小时后恢复，好像什么都没发生过一样，导致订阅服务器中的数据出现 3 个多小时的空白。例如，复制在凌晨 3:30 停止，然后在早上 6:30 恢复，但在 3:30 到 6:30 之间没有复制任何数据。
未发现任何复制错误，没有数据库/服务器错误，复制监视器显示零延迟。事务日志非常大（61% 容量），但除此之外没有发现任何错误。在 3 小时内没有复制任何内容，sp_replmonitorsubscriptionpendingcmds 显示没有待处理事务。
我之所以能够确定数据停止流动，是因为我们有一个表不断记录应用程序事件。在此期间运行的唯一作业是重建一个约 10 亿行的大型表的索引。该作业在复制停滞前 30 分钟启动，总共持续了 40 分钟。
我们的环境由两个配置为对等事务复制的大型数据库组成。我们没有像预期的那样利用环境。我们不是读写两个数据库，而是一个数据库作为面向客户的主要数据库，另一个数据库用于实时报告。我们最初认为，如果主数据库损坏，对等是一种廉价的灾难恢复解决方案。到目前为止，我们还没有这样使用过，事后看来，应该使用简单的事务复制。
一旦发布者和订阅者数据库之间的复制再次开始流动，复制监视器就会显示一些延迟，而 sp_replmonitorsubscriptionpendingcmds 会显示待处理事务。大约 90 分钟后，延迟为零，一切恢复正常，但订阅者的数据存在 3 小时以上的差距。
我不明白在没有错误的情况下这种情况是如何发生的？我猜想如果复制突然停止，那一定是因为异常而发生的。我进行了一些谷歌搜索，找到了一些有关复制代理停止的信息，但尚无定论。我不知道发生了什么，也没有什么可继续的。有人知道解决此问题的最佳方法吗？过去有人遇到过这种情况吗？有人能帮我指出正确的方向吗？任何帮助都将不胜感激。