我们有一个合并发布，它在大约 80 篇文章中使用了一系列复制方法（一个表上的主机名过滤，其他几个表的连接过滤；一些表使用双向同步方向，另一些表使用“仅下载，禁止订阅者更改”；一些使用身份范围管理的表，其他人不需要它）。
我们正在使用推送复制到已经拥有所有必要表的订阅者数据库，因此我们使用“删除数据”来执行“如果名称正在使用中的操作”。这些表在订阅者和发布数据库上具有相同的架构，但在复制启动之前都是空的。
问题是订阅的初始化有时需要约 3 分钟，但有时会在约 20 分钟后超时，使用相同的模板订阅数据库和相同的起始数据集（约 10,000 条记录）。初始化后，同步时，不再需要约 5 秒，而是再次需要约 20 分钟。查看复制监视器中的历史记录，同步历史记录表明它正在进行 1000 次模式更改（即使没有数据更改）。
我打开详细日志记录以查看架构更改是什么，它似乎在所有表中反复循环，关闭所有约束，然后再次打开。我不知道为什么要这样做。
请注意是否相关：我一直使用 100 个字符的 unicode 字符串（从完整的 unicode 字符范围随机创建）作为不同订阅者的 host_name。我怀疑这可能是导致问题的原因，但我已经使用 50 个字符的小写字母字符串重现了该问题。
最后，所有服务器都托管在同一个数据中心，所以我认为网络延迟不是问题。