我在同一实例的发布者和订阅者上运行了一些简单的测试:
- 我在一篇已发表的文章中插入了 50,000 行,数据被正确地推送给了订阅者。
- 我无意中删除了订阅者上的第 49,985 条记录(但当时没有意识到)
- 我从发表的文章中删除了 50,000 行
当我观察订户表的大小时,我注意到它的行数几乎下降到零,然后又回到 50,000。删除将再次开始运行,行数将下降,然后又回到 50,000。这种情况一遍又一遍地发生。
我运行了标准跟踪并看到所有删除都在正常运行。差不多完成后,出现了这样的语句:
IF @@TRANCOUNT > 0 ROLLBACK
然后我修改了跟踪以包含错误消息并看到了这个:
The row was not found at the Subscriber when applying the replicated command.
所以看起来当分发代理正在一个一个地执行所有删除时,该过程仍然包含在一个事务中(原来的 DELETE 是一行)。如果出现错误,它会执行 ROLLBACK,然后重新开始。
我的问题:
- 有没有标准的方法来跳出循环?
- 是否可以重新创建丢失的行以完成流程?
- 如果在生产中发生这种情况,您会怎么做?我想这不是一个真正的问题。但这似乎是一个简单的错误,除非非常仔细地监控复制,否则可能会导致一些相当严重的并发症。
错误原因是每篇文章的自定义删除存储过程中的代码:
如果没有行被删除,一个特殊的过程被调用并且事务被回滚。
为了避免这种情况,我创建了一个快照后脚本,它更改所有删除/更新复制存储过程并将错误记录到一个表中。