对于我们的SaaS应用程序，我希望有一个适用于数据中心广泛故障的系统。
在主数据中心，我们有两台使用MSSQL数据库镜像（同步）的服务器。 这为我们提供了一个足够好的高可用性服务器故障解决scheme。 如果服务器死了，它会在几秒钟内自动故障转移（在第三个见证服务器的帮助下）。
我正在考虑使用镜像数据库中的MSSQL复制或日志传送 ，以将热备份服务器保留在另一个数据中心 – 注意这将是跨大西洋的，因此高达100ms。 我想我可以使用一些短暂的（5分钟）TTL的DNS故障转移服务，在第一个数据中心发生故障时将stream量引导到第二个数据中心。
问题：
我可以使用复制或日志传送从镜像数据库（无缝工作，如果它故障转移到另一个实例）？
哪一个是首选的 – 复制或日志传送或别的东西？
是否有可能让故障转移数据库接受写入？
或者是否会有潜在的故障转移数据丢失，最好只有在我们恢复到主数据中心之前才能进行只读操作？
谢谢！
编辑：任何人有任何想法的备用MSSQL服务器configuration？
日志传送或复制都可以使用数据库镜像 – 您应该使用哪一个取决于您的要求，但是复制可能比日志传送更难以设置和pipe理，因此我个人坚持使用日志传送，除非您有一个复制function真的需要。 以下链接提供了有关如何设置每个的更多信息。
是否有可能让故障转移数据库接受写入？
注：我假设你的意思是一旦故障转移发生，而不是在日常的正常运行。
当然，使用日志传送function，可以让辅助DC中的故障转移数据库接受写入。 如果您可以采取和应用在主DC中运行的数据库的尾部日志备份（以最大限度地减less数据丢失并保持日志链完好无损），那么您将拥有运行的最新数据库副本不要忘记，在这种情况下你正在暴露。 定期的日志备份可以提供帮助，但是如果您的目标不会丢失任何交易，那么当您仅在另一个DC的日志传送辅助服务器上运行时，这将无法得到保证。 在只读状态下运行应用程序可能会更好，直到您重新设置HA。 在此状态下，您可以将日志备份复制到主数据中心，然后重新初始化镜像。
有用的链接：
http://msdn.microsoft.com/en-us/library/ms187016.aspx – 日志传送和数据库镜像http://msdn.microsoft.com/en-us/library/ms151799.aspx – 复制和数据库镜像
注意：要获得对logshipping数据库的写入访问权限，您需要将RESTORE DATBASE dbname WITH RECOVERY然后它可以像master一样写入，但是在执行此操作后无法恢复任何其他日志。 您需要恢复新的完整备份才能使重新运行。 但是，这样做可以让你对它进行故障切换。
我正处于类似的计划阶段，而不是在全球范围内，而是在整个美国。 我们正在计划与日志传送。 看起来（至less对我来说）比复制（我曾经工作过）更强大，更容易pipe理，更容易设置（至less对我来说）。
这是一个利弊的快速列表。 对我们来说最大的挑战是没有像镜像一样的自动故障转移。
一般来说，你在一个很好的路线，但考虑以下几点：
这就是为什么这提供有限的医pipe局增加的原因。 高达24小时的caching并不less见。 我build议这更多的是一种灾难恢复方法，因为只有当您的主站点受到更长时间的影响时，您才会想要这样做，因为故障恢复也需要24小时才能传播给某些客户端。