我正在尝试为在 Windows 2008 R2 Web Edition/SQL Server 2008 R2 Web Edition 上运行的 ASP.NET MVC 网站实现自动故障转移。我知道此功能不支持开箱即用，但我必须使用目前可用的软件许可证。
自动故障转移是指，一旦发生灾难，辅助服务器应启动，并恢复主服务器数据库中的所有数据。如果这不可行，我也很乐意恢复“所有数据（过去 5 分钟内写入数据库的数据除外）”。
如果有必要，我很乐意切换回主服务器。
以下是我目前想到的：
设置以非常小的时间间隔（5 分钟）将日志从主服务器的数据库传送到辅助服务器。数据库不是太大（<50 MB），写入很少，因此希望这不会对性能产生很大的影响。我更喜欢镜像，但 SQL Server Web 版不支持镜像
始终将网站部署到两台服务器
使用 DnsMadeEasy (dnsmadeeasy.com) 监控主服务器，并在主服务器出现故障时动态切换到辅助服务器
在辅助服务器上运行服务任务，每分钟监控一次 DNS 条目。如果它指向辅助服务器，则尝试触发另一次日志传送运行（以防主 Web 服务器关闭，但主数据库仍在运行）。最后但并非最不重要的是停用日志传送。
您觉得如何？有没有更简单的方法可以做到这一点（无需使用其他数据库或云解决方案）？
谢谢，
阿德里安
答案1
根据位于的高可用性信息这里，Web 版本的唯一选项是日志传送。（复制也不是一种选择，尽管我只建议在有限的情况下这样做，因为它对应用程序的数据库模式非常具有侵入性。）
话虽如此，如果您可以容忍几分钟的数据丢失，日志传送就会非常好。
但是，“自动”是有风险的。需要注意以下几点：日志传送故障转移不是自动的。“监控服务器”只是监控，它不会在出现问题时采取行动。某些东西或某些人必须决定原始服务器已关闭，并且故障转移服务器上的数据库应该退出恢复。您可以编写一个程序来执行此操作，但这会带来风险，或者如果您有 24x7 监控，则依赖人工，这会使五分钟的停机时间窗口非常不舒服。
无论您有什么作业（无论是备份和重新索引等“管理”内容还是特定于您的应用程序的内容），它们都应该存在于两台服务器上，但它们不应该在您需要之前在故障转移上运行。如果您有大量作业，您将需要某种自动化的方式来启用/禁用它们。最近有一篇关于这方面的文章，我现在找不到它，但你应该能够通过谷歌搜索找到一些可以给你灵感的东西。
软件包、链接服务器和任何其他服务器级内容也是如此。这些对象应始终位于两台服务器上，并且您无法将这些对象的更改从主服务器“记录”到故障转移服务器。在复杂的服务器配置下，保持两台服务器上的内容一致可能是一项需要大量时间或某些软件的任务。
您需要确保两台服务器上的登录名、密码和 SID 匹配。如果不匹配，您的 Web 应用在启动时可能无法访问故障转移服务器上的数据库。如果您使用域安全性作为应用登录，则这会更容易，因为您无需担心 SID。如果您使用 SQL Server 安全性，则需要更加小心。
主服务器和故障转移服务器将具有不同的主机名。您需要一种方法来将 Web 应用程序的数据源从 SQLServer A 更改为 SQLServer B。我们使用 DNS C 名称，因此我们可以更新 DNS 中的条目，而不是更新 Web 服务器上的文件。
当然，您希望在真正需要它之前对其进行测试。
如果您计划每月一次的 Windows 补丁停机，则应将手动故障转移集成到修补服务器的过程中。这将最大限度地减少应用程序的停机时间，测试故障转移过程，并为执行工作的人员提供真实的演练。
与由于实际紧急情况而进行故障转移相比，您因修补窗口和类似事项而进行故障转移的次数可能会更多。
手动故障转移测试您的流程，以便您知道在真正的紧急情况下是否有效。它还迫使您从另一个方向重新设置日志传送，如果您有一个大型数据库，这可能需要大量时间。