jack Asked: 2019-12-26 18:45:17 +0800 CST2019-12-26 18:45:17 +0800 CST 2019-12-26 18:45:17 +0800 CST 订阅者节点在事务复制中关闭 772 1）我有 2 个节点，其中节点 1 是同一服务器中的发布者和分发者，节点 2 中的订阅者。如果发布者关闭了几个小时，我需要通过禁用复制来启动订阅者进行读写，事务和节点 1 分发数据库中的命令将被回滚或者我会丢失某些数据？ 2）我有节点 1 是发布者，节点 2 有分发者和订阅者，以防发布者关闭几个小时，我需要启动订阅者进行读写。在发布者中标记为复制但尚未发送到分发者的事务会发生什么情况，它会回滚还是我会丢失某些数据？ 谢谢 sql-server transactional-replication 1 个回答 Voted Best Answer David Browne - Microsoft 2019-12-27T08:53:21+08:002019-12-27T08:53:21+08:00 首先，您不应该将复制用于高可用性或灾难恢复。它从来都不是为此而设计的，你会在下面看到这不是一个很好的解决方案 相反，如果您打算将解决方案用于高可用性或灾难恢复，则应该真正使用AlwaysOn 可用性组而不是复制。 我需要通过禁用复制来启动订阅者进行读写，节点 1 分发数据库中的事务和命令是否会回滚 不会。旧的发布商/分销商将在它出现故障的时间点恢复。 或者我会丢失某些数据？ 您将在每个数据库中拥有另一个数据库中不存在的数据。您可以丢弃其中一个或另一个中的数据，或者手动将更改从一个添加到另一个，可能使用tablediff实用程序。 在发布者中标记为复制但尚未发送到分发者的事务会发生什么情况，它会回滚还是我会丢失某些数据？ 发布者将重新上线，任何已提交但未分发的事务都将出现在发布者中，但旧的分发者不再读取其事务日志文件。同样，以前的订阅者现在拥有旧发布者中不存在的数据，您必须决定要做什么。 此处的典型操作响应是保存旧发布者的副本，然后使用来自旧订阅者的数据重新创建和重新初始化复制。您可以通过将旧订阅者配置为新发布者，或者通过在旧发布者上恢复旧订阅者的备份并重新创建旧复制拓扑来执行此操作。
首先，您不应该将复制用于高可用性或灾难恢复。它从来都不是为此而设计的，你会在下面看到这不是一个很好的解决方案
相反，如果您打算将解决方案用于高可用性或灾难恢复，则应该真正使用AlwaysOn 可用性组而不是复制。
不会。旧的发布商/分销商将在它出现故障的时间点恢复。
您将在每个数据库中拥有另一个数据库中不存在的数据。您可以丢弃其中一个或另一个中的数据，或者手动将更改从一个添加到另一个，可能使用tablediff实用程序。
发布者将重新上线，任何已提交但未分发的事务都将出现在发布者中，但旧的分发者不再读取其事务日志文件。同样，以前的订阅者现在拥有旧发布者中不存在的数据，您必须决定要做什么。
此处的典型操作响应是保存旧发布者的副本，然后使用来自旧订阅者的数据重新创建和重新初始化复制。您可以通过将旧订阅者配置为新发布者，或者通过在旧发布者上恢复旧订阅者的备份并重新创建旧复制拓扑来执行此操作。