SQL Server 简单冗余

Question

我是这里的新手，想请教各位专家，了解配置两个 SQL Server（2008 R2 及更高版本）的首选方法，以实现具有以下特征的简单冗余：

1. 有 2 台计算机。每个都有自己的 SQL Server，还有自己的 Windows 服务定期将时间戳数据写入数据库。该服务已有自己的简单切换/故障转移算法。

2. 对于数据库的行为，一旦主服务器下线，备份计算机的服务将接管将数据写入备份数据库。客户端会知道，由于主服务器已关闭，它将重新连接到备份以进行数据检索。

3. 现在，当主计算机重新上线时，这台计算机中的服务将开始向数据库写入数据，而备用计算机中的服务将停止。

4. 从这里开始，需要一个合适的同步计划来确保备份数据库中的数据将被同步，或传输回主数据库以保持完整性。事实上，即使主数据库不离线，两个数据库也应该同步。

根据我上面的描述，我浏览了几篇文章，得出了 3 种可能的候选方法：

1. 合并复制
2. 镜像
3. 额外的自定义编程 - 真的是最后的手段，但如果需要，我将不得不亲自动手

作为最近的 MS 技术在长时间的中断之后的后来者，我最初有点迷茫。在阅读这些文本时，我找不到关于这些方法是否支持上述行为 (4) 的明确指示。

据我了解，方法（2）在我们的案例中不起作用，因为在故障转移后，备份数据库成为“主体”，主数据库成为“镜像数据库”。根据我的阅读，镜像数据库处于脱机状态，无法访问。请注意上面（3）中的windows服务行为。

至于方法（1），我对它如何（或不会）工作感到困惑。比如我理解Publishing和Subscribing的概念，所以Primary DB将被配置为发布者，Backup DB将被配置为subscriber。为了合并，还需要将备份数据库配置为发布者，反之亦然。在这种情况下，假设 Primary 中的服务正在将数据写入 DB，然后将其发布到 Backup DB。然后，备份数据库再次将其发布回主数据库（全部基于触发器）。这里似乎是一个无限循环。

我希望我的假设是相当正确的。我错过了什么？

注意：这些服务器只会在一周后到达，所以我现在没有什么要测试的。只能做理论上的准备。

感谢和问候。

Answer 1

如果您真的需要可信度而不花费大量时间，我建议您使用标准解决方案database mirroring。 Automatic failover 使用 witness 机器来处理数据库通信，因此客户端应用程序甚至不知道数据库服务器上是否发生此类故障。因此，您对第（3）点的担忧不会

但是，这种架构给您留下了单点故障，即见证。如果见证失败，则必须使用冗余策略。好处是这个新的恢复过程，不会包含数据库恢复过程本身。

希望我能帮上忙！

Answer 2

合并复制是可行的。在合并复制中，您发布到订阅者。同步发生时，订阅者所做的任何更改都会在发布者处进行。如果发布者离线，则订阅者的更改将在发布者重新上线并同步时复制到发布者。