我试图为在Windows 2008 R2networking版/ SQL Server 2008 R2networking版上运行的ASP.NET MVC网站实现自动故障转移。 我知道这不是开箱即用的支持，但是我必须处理目前正在使用的软件许可证。
通过自动故障转移，我的意思是，如果发生灾难，辅助服务器应该使用来自主服务器数据库的所有数据。 如果这不是一个选项，我也很高兴“所有数据less于在过去5分钟内写入数据库”。
如果有必要，我很乐意切换回主服务器。
以下是我到目前为止所做的：
使用非常短的时间间隔（5分钟）从主服务器的数据库安装日志传送到辅助服务器。 数据库不是太大（<50 MB），写入很less，所以希望这不会有很大的性能影响。 我宁愿镜像，但不支持SQL Servernetworking版
始终将网站部署到两台服务器
使用DnsMadeEasy（dnsmadeeasy.com）监视主服务器，如果主服务器出现故障，则dynamic切换到辅助服务器
在次要服务器上运行服务任务，每分钟监视一次dns项目。 如果它指向辅助，则尝试触发一个日志传送运行（如果主Web服务器closures，但主数据库仍在运行）。 最后但并非最不重要的停用日志传送。
你怎么看？ 有没有更简单的方法来做到这一点（使用不同的数据库或云解决scheme）？
谢谢，
阿德里安
根据位于此处的高可用性信息，Web版本的唯一选项是日志传送。 （复制也不是一个选项，虽然我只会build议，在有限的情况下，因为它是非常侵入应用程序的数据库模式。）
话虽如此，如果你能忍受几分钟的数据丢失，日志传送可以是非常好的。
然而，“自动”是有害的。 有些事情要记住：日志传送故障转移不是自动的。 “监控服务器”只是监控，当出现问题时不会采取行动。 某事或某人将不得不决定原始服务器已closures，并且故障切换服务器上的数据库应该被带出恢复。 你可以编写一个程序来做到这一点，如果你有全天候的监控，这会带来风险，或者依靠人类，这使得五分钟的停机时间非常不舒服。
无论你有什么工作（无论是“pipe理员”，比如备份和重新索引或者特定于你的应用的东西），都应该存在于两台服务器上，但是不应该在故障转移之前运行，直到你需要为止。 如果你有大量的工作，你将需要某种自动化的方式来启用/禁用它们。 刚才有一篇关于这方面的文章，我现在找不到，但是你应该可以find一些东西给你一些使用Google的想法。
同上的包，链接服务器和任何其他服务器级别的东西。 这些对象应始终位于两台服务器上，并且不能将这些对象的更改从主服务器“logging”到“故障转移服务器”。 使用复杂的服务器configuration，在两台服务器上保持一致可能是需要大量时间的任务，或者是一些软件。
您需要确保两台服务器上的login名，密码和SID匹配。 否则，您的Web应用程序启动时可能无法访问故障转移服务器上的数据库。 如果您为您的应用程序的login使用域安全性，这将更容易，因为您不必担心SID。 如果您正在使用SQL Server安全性，则需要更加小心。
主服务器和故障转移服务器将具有不同的主机名称。 您将需要一种方法将您的Web应用程序的数据源从SQLServer A更改为SQLServer B.我们使用DNS C名称，因此我们可以更新DNS中的条目而不是更新Web服务器上的文件。 。
当然，你要在真正需要它之前testing一下。
如果计划中断每月一次的Windows修补程序，则应将手动故障转移集成到修补服务器的过程中。 这将最大限度地减less应用程序的停机时间，testing故障转移过程，并为执行任务的人员提供现实的演练。
你可能会失败多次修补窗口和类似的东西，而不是由于真正的紧急情况而失败。
手动故障检测你的过程，所以你知道是否会在真正的紧急情况下工作。 这也迫使您将日志传送设置为另一个方向，如果您拥有大型数据库，这可能会花费大量的时间。