我们正在运行一个支付（EFT 交易处理）应用程序，该应用程序全天候处理大量交易，目前正在研究一种更好的方法将数据库复制到我们的灾难恢复站点。
我们当前和以前的策略包括使用 DoubleTake 和 Redgate 将数据复制到热备用。
DoubleTake 是支付软件供应商支持的解决方案，但他们 (DoubleTake) 在南非的支持非常差。我们遇到了一些问题，根本无法解决，所以我们不得不放弃 DoubleTake。
我们一直在使用 Redgate 手动从主站点读取数据（通过查询）并写入 DR 站点，但这是：
- 糟糕的解决方案
- 每当我们遇到支持问题时，软件供应商就会感到烦恼，因为它往往会干扰数据库密集型的支付应用程序。
我们最近将整个系统升级为在 SQL 2008 R2 Enterprise 上运行，这意味着我们可能应该考虑使用一些内置的复制功能。
该服务器有 2 个相当大的数据库，其中混合了包含高度易变的交易数据和相当静态的配置数据的表。
复制将通过 WAN 链接完成到单独的物理站点，并需要实现以下目标。
RPO：零损失 - 这是具有财务影响的交易数据，因此我们不能丢失任何东西。RTO：趋于零 - 业务取决于我们处理交易的能力，每分钟停机都会造成资金损失
我查看了其他一些问题/答案，但没有一个完全符合我们的情况：
我目前的想法是我们应该使用镜像，但我担心对于 RPO：0，我们需要进行延迟提交，这可能会影响主数据库的性能，而这不是一个选择。
我们当前的 DR 流程是：
- 停止进入主站点的传入流量并允许所有正在进行的交易完成。
- 允许完成到 DR 的复制。
- 更改网络路由以路由到 DR 站点。
- 启动辅助站点上的所有应用程序和服务（理想情况下，我们可以将其更改为更温暖的待机状态，即应用程序已经在运行但不处理任何交易）。
换句话说，DR 数据库需要尽快赶上主数据库并准备好作为新的主数据库进行处理。然后，当我们准备切换回来时，我们需要能够逆转这一过程。
有没有比镜像更好的选择（我们也应该进行日志传送）？有人可以建议我们应该牢记的其他注意事项吗？
答案1
您问的问题很正确，而且很好地解决了问题，但是门槛太高了。您在寻找五年前开发的技术可能无法实现的东西时遇到了瓶颈。而且您已经在该领域测试了两家供应商，但他们无法应对挑战。
为未来做计划。你现在拥有的就是它。你可以尝试重新设计现有或较旧的技术，但转向下一个版本可能是一个值得研究的选择。
我怀疑您描述的 2008 镜像的缺点就是 Microsoft 在 SQL Server 2012 中引入 AlwaysOn 功能的原因。除非您与镜像的连接延迟较高并且使用高安全模式，否则 2008 镜像实际上相当不错。如果您有大量交易并且要处理金钱，那么高安全性或高性能就不是容易做出的决定。
我自己的预测是，所谓的“云”提供商实际上将成为许多灾难恢复场景的天然选择。他们拥有大多数公司负担不起的技术和专业知识，并且正在挑战极限。
异步数据库镜像（高性能模式）
http://msdn.microsoft.com/en-us/library/ms187110%28v=sql.105%29.aspx
SQL Server AlwaysOn 简介
http://msdn.microsoft.com/en-us/sqlserver/gg490638
SQL Server 2012 AlwaysOn 常见问题解答
http://msdn.microsoft.com/en-us/sqlserver/gg508768.aspx
答案2
您还可以在存储级别进行复制。因此，您可以在应用程序层（数据库）和存储级别进行复制。
由于此应用程序对于较低的 RPO 和 RTO 至关重要，因此您可以寻找同步镜像，以便在主端出现增量时立即进行更新。
云是一个不错的选择。它提供了出色的灵活性、速度、即用即付模式、规模经济、全球覆盖等，但由于这是支付和银行业务相关的要求，因此您应该选择私有云以获得更好的安全性。另一方面，私有云将大大增加您的运营支出和总体成本。
因此，您可能会考虑在软件和基础设施层面采用复制技术。