我在这里是一个新手，并想请所有专家在这里介绍配置两个SQL Server（2008 R2及以上版本）的首选方法，以获得具有以下特征的简单冗余：
有2台电脑。每个都有自己的SQL Server，还有自己的Windows服务，定期向DB写入带时间戳的数据。该服务已经有了自己的简单切换/故障转移算法。
对于数据库的行为，一旦主服务器脱机，备份计算机的服务将接管将数据写入备份数据库。客户端将知道，由于主服务器已关闭，它将重新连接到备份以进行数据检索。
现在，当主服务器重新联机时，此计算机中的服务将开始将数据写入数据库，而备份计算机中的服务将停止。
从这里开始，需要一个合适的同步计划，以确保来自备份数据库的数据将被同步，或者传输回主数据库以保证完整性。实际上，即使主数据库未脱机，也应同步两个数据库。
根据我上面的描述，我已经阅读了几篇文章并得出了3种可能的候选方法：
作为长期中断后最近进入MS技术的后来者，我最初有点迷失。在阅读这些文本时，我无法找到明确的指示，关于方法是否支持如上所述的行为（4）。
据我所知，方法（2）在我们的情况下不起作用，因为在故障转移后，备份数据库变为“主体”，主数据库变为“镜像数据库”。根据我的阅读，Mirror DB处于脱机状态，无法访问。请注意上面（3）中的Windows服务行为。
对于方法（1），我很困惑它将如何（或不会）工作。例如，我理解发布和订阅的概念，因此主数据库将配置为发布者，备份数据库将成为订阅者。为了合并，备份数据库还需要配置为发布者，反之亦然。在这种情况下，假设主服务器中的服务正在将数据写入数据库，然后将其发布到备份数据库。然后，备份数据库将再次将其发布回主数据库（所有基于触发器）。这似乎是一个无限循环。
我希望我的假设是正确的。我错过了什么？
注意：这些服务器只会在一周内到达，所以我现在没有什么可以测试的。只能在理论上做好准备。
谢谢和问候。
答案 0 :(得分：1)
如果你真的需要信誉而不花很多时间，我建议你选择database mirroring的标准解决方案。 Automatic failover使用见证机器来处理数据库通信，因此客户端应用程序甚至不知道数据库服务器上是否发生了这样的故障。因此，您对第（3）点的担忧不会
但是，这种架构会让您单点故障，见证。如果见证失败，则必须使用冗余策略。优点是这个新的恢复过程本身不包括数据库恢复过程。
希望我帮忙！
答案 1 :(得分：0)
合并复制是可行的。在“合并复制”中，您将发布到订户。订阅者所做的任何更改都是在发布同步时在发布者处进行的。如果发布者脱机，则订阅者的更改将在重新联机并同步时复制到发布者。