混合事务复制和日志传送？
我使用推送事务复制将一个大型数据库（接近 1TB）复制到三个远程服务器。订阅者是只读的。每个月的某一天都会插入和更新大量数据（从其他来源）。它总是在一天之后复制失败，我们每月从备份手动初始化复制。
是否可以在插入日之前切换到日志传送，并在批量插入日志传送之后切换回事务复制？那么不需要复制大备份文件来重新初始化吗？
I've replicated a large database (close to 1TB) to three remote servers using pushing transactional replication. The subscribers are read-only. A lot of data is inserted and updated (from other sources) in one day every month. It always fail the replication after the day and we manually initialize the replication from backup every month.
Is it possible to switch to log shipping before the inserting day and switch back to transactional replication after the bulk insertions are log shipped? So there is no need to copy the big backup file for re-initialization?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
不。事务复制是逻辑性的，而日志传送是物理性的。两者之间不能随意切换。但是，如果您的订阅者一开始就是只读的，那么事务复制可以用日志传送来替换，但代价是更新会稍微延迟，并且每次日志传输时都必须断开备用站点上的读取器。应用（通常这远没有听起来那么糟糕）。与事务复制相比，考虑到日志传送的效率更高且问题更少，我会毫不犹豫地永久进行此替换。
No. Transactional replication is logical while log shipping is physical. You can't switch at will between the two. But if your subscribers are read only to start with then transactional replication can be replaced out of the box with log shipping, at the cost of a slight delay in updates and having to disconnect readers on the stand-by sites every time a log is being applied (usually this is nowhere near as bad as it sounds). Given how much more efficient and less problematic log shipping is compared to transactional replication, I would not hesitate for a single second in doing this replace for good.
我怀疑您是否需要按计划重新初始化。我已经让复制拓扑运行了很长一段时间而无需重新初始化。当我们这样做时，只是因为架构发生了变化，效果不太好。当你说大量数据复制失败时，是什么意思？复制很乐意将大量数据更改传递给订阅者。如果您遇到延迟限制，您可以增加延迟限制或在发布商处将大型事务分解为较小的事务。您还可以选择为日志读取器代理设置 MaxCmdsInTran 选项，让它为您分解事务。
I question your need to re-initialize on a scheduled basis. I've had replication topologies go for a really long time without having the need to re-init. And when we did, it was only because there was a schema change that didn't play nice. When you say that the large amount of data fails replication, what does that mean? Replication will gladly deliver large data changes that to the subscribers. If you're running afoul of latency limits, you can either increase those or break down large transactions into smaller ones at the publisher. You also have the option of setting the MaxCmdsInTran option for the log reader agent to have it break up your transactions for you.