使用SQL 2008 R2实现零和最低可能的RTO (小于15分钟)的最佳方法是什么？

Question

我们正在运行一个支付(EFT事务处理)应用程序，该应用程序处理大量的24/7事务，目前正在研究一种更好的将DB复制到灾难恢复站点的方法。

我们目前和以前的策略包括使用DoubleTake和Redgate来复制数据到一个温暖的备用状态。

DoubleTake是由支付软件供应商支持的解决方案，但是他们在南非的(DoubleTake)支持非常差。我们有一些问题，根本解决不了，所以我们不得不放弃DoubleTake。

我们一直在使用Redgate从主站点(通过查询)手动读取数据并写入DR站点，但如下所示：

1. 不好的解决办法
2. 每当我们有支持问题的时候，软件供应商就会感到烦躁不安，因为它有干扰支付应用程序的倾向，这是非常密集的DB。

我们最近对整个系统进行了升级，使其在SQL2008WebEnterprise上运行，这意味着我们应该考虑使用一些内置的复制特性。

服务器有两个相当大的数据库，其中包含高度易失性的事务性数据和相当静态的配置数据的混合表。

复制将通过WAN链接到一个单独的物理站点，并需要实现以下目标。

RPO:零损失--这是有财务影响的交易数据，所以我们不能失去任何东西。RTO:趋向于零--业务取决于我们处理交易的能力，每一分钟我们都在亏损。

我看过其他几个问题/答案，但没有一个完全符合我们的情况：

1. 服务器2008故障转移策略-日志传送还是复制？
2. 如何使用Server通过日志传送实现以下RTO &RPO？
3. 实现DB复制的两种方法中最好的是什么？

我目前的想法是我们应该使用镜像，但我担心对于RPO:0，我们需要执行延迟提交，这可能会影响主DB的性能，这不是一个选项。

我们目前的DR程序是：

1. 停止到主站点的传入流量，并允许所有飞行中事务完成.
2. 允许复制到DR完成。
3. 将网络路由更改为路由到DR站点。
4. 启动次要站点上的所有应用程序和服务(理想情况下，我们可以将其更改为一个更温暖的备用状态--在这里，应用程序已经在运行，但没有处理任何事务)。

换句话说，DR数据库需要尽快赶上主数据库，并准备作为新的主数据库进行处理。这样，我们就需要能够在我们准备回去时扭转这一局面。

有没有比镜像更好的选择(我们也应该做日志传送)，还有谁能建议我们应该记住的其他考虑呢？

Answer 1

你提出了正确的问题，并对这个问题有了很好的处理，但是标准设定得相当高。你正碰壁寻找一些五年前开发的技术可能难以实现的东西。而且你已经有了测试驱动的两个供应商在这个领域，他们不适合挑战。

为未来做计划。你现在拥有的就是它是什么。您可以尝试重新设计现有或较旧的技术，但转向下一个版本可能是值得研究的选择。

我怀疑您所描述的2008镜像的缺点就是为什么微软在Server 2012中引入了AlwaysOn功能。2008年镜像实际上是相当好的，除非您有一个高延迟连接到镜像，并正在使用高安全模式。如果你有大量的交易并且在处理金钱，那么高安全性或高性能并不是一个容易的决定。

我自己的预测是，所谓的“云”提供商实际上将是一个自然适合许多DR方案。他们拥有大多数公司负担不起的技术和专业知识，并且正在对可能的事情紧追不舍。

异步数据库镜像(高性能模式)

http://msdn.microsoft.com/en-us/library/ms187110%28v=sql.105%29.aspx

介绍Server

http://msdn.microsoft.com/en-us/sqlserver/gg490638

用于Server 2012的AlwaysOn常见问题

http://msdn.microsoft.com/en-us/sqlserver/gg508768.aspx

Answer 2

您还可以在存储级别进行复制。这样，您就可以在应用层(您的数据库和存储级别)上获得复制。

由于此应用程序对于低RPO和RTO至关重要，因此您可以查找同步镜像，以便在主侧有一个增量时立即进行更新。

云是一个不错的选择。它提供了极大的灵活性，速度，随走付费模式，规模经济，全球范围等，但由于这是支付和银行相关的要求，你应该选择私有云更好的安全。另一方面，私有云将大大增加您的opex和总体成本。

因此，您可以考虑在软件和基础设施级别上使用复制技术。