假设您需要确保依赖于SQL Server 2012的应用程序全天候可用，因为它的数据库后端即使一台服务器计算机出现故障也是如此。

作为开发人员而不是DBA，我努力了解何时使用哪种方案进行故障转移/高可用性：

• Windows故障转移群集中的两台（或更多）服务器，SQL Server作为群集实例
• 两个（或多个）SQL Server实例与事务复制保持最新
• SQL Server可用性组中的两个（或更多）SQL Server，以同步提交模式配置

这些方案中的每个方案都适合哪种工作负载，这些方案可以处理哪种故障/停机？它们是否具有可比性/可互换性？

我一直喜欢可视化高可用性解决方案的方式如下：

SQL Server故障转移群集实例（FCI）

什么是高可用？ 整个实例。这包括所有服务器对象（登录，SQL Server代理作业等）。这也包括数据库及其包含的实体。对于高度可用的SQL Server实例，这是一个很好的解决方案，因为这将成为此给定解决方案的包含级别。

报告呢？ 无，NULL，不存在。故障转移群集实例具有一个活动节点，该节点提供包含该实例，VNN等的群集组，而所有其他节点均为被动节点，处于空闲状态（就当前群集组而言），并等待故障转移。

故障转移时会发生什么？ FCI的停机时间将由被动节点获取群集资源并使SQL Server实例进入运行状态所花费的时间确定。这通常是最短的时间。

任何客户端抽象？ 是的，它将使用故障转移群集实例的虚拟网络名称固有地内置。这将始终指向当前正在传递SQL Server群集资源的活动节点。

AlwaysOn可用性组

什么是高可用？ 在这里，可用性组将成为高可用性的逻辑约束，而可用性组则由多个数据库和一个虚拟网络名称（侦听器，可选的群集资源）组成。值得注意的是，诸如登录名和SQL Server Agent作业之类的服务器对象将不会成为HA解决方案的一部分，并且需要特别注意以确保使用可用性组正确实现这些对象。这不是一个负担过重的要求，但需要予以照顾。

报告呢？尽管我可能不会使用同步副本作为报告实例，但这是一个很好的报告解决方案。有两种提交关系，同步和异步。从我的观点以及我在实践中所看到的来看，就是您的同步辅助副本在那里等待灾难。可以将其视为可以在发生问题时进行无数据丢失故障转移的副本。然后是可以处理该报告工作负载的异步副本。您并没有使用此副本作为上述解决方案，而是将其用于报告之类的事情。可以将报告工作负载指向此副本（直接或通过侦听器通过只读路由间接指向）。

故障转移时会发生什么？ 对于与自动故障转移配对的同步提交辅助副本，这将是副本角色状态从SECONDARY_NORMAL更改为PRIMARY_NORMAL。为了进行自动故障转移，您需要有一个当前处于同步状态的同步辅助副本，并且实施的是“ 灵活故障转移策略”来确定实际上何时应该进行此故障转移。该策略确实是可配置的。

任何客户端抽象？ 是的，您可以选择配置AlwaysOn可用性组侦听器。这基本上只是指向当前主副本的虚拟网络名称（可以通过WSFC视为AG群集组中的群集资源）。这是转移报告工作量的关键部分，并且在要重定向只读流量的任何服务器上设置只读路由列表（这是通过.NET Framework Provider for SQL通过连接字符串设置的）服务器，这将是Application Intent参数，设置为ReadOnly。您还需要为要在辅助副本角色中接收此报告工作负载的每个副本设置一个只读路由URL。

事务复制

什么是高可用？ 这是有争议的，但是我什么也不会说。我不认为复制是任何高可用性解决方案。是的，数据修改正在推送给订户，但我们正在出版物/文章级别进行讨论。这将是数据的子集（可以包括所有数据，但是不会强制执行。即，您在发布者数据库中创建了一个新表，并且不会自动将其推送给订阅者）。就HA而言，这是最底层的，我不会在其中使用坚如磐石的HA解决方案。

报告呢？ 毫无疑问，这是报告子数据的绝佳解决方案。如果您具有一个具有高事务性的1 TB数据库，并且希望将该报告工作负载保留在OLTP数据库之外，那么事务复制是将数据子集推送到一个或多个订户的报告方法的好方法。如果在这1 TB数据中，您的报告工作负载仅约50 GB，会发生什么？这是一个智能解决方案，可以相对配置以满足您的业务需求。

摘要

归结为一些需要回答的问题（部分由企业）：

1. 什么需要高度可用？
2. 什么是SLA规定的HA / DR？
3. 将进行哪种报告，可以接受哪些延迟？
4. 对于地理位置分散的 HA，我们需要处理什么？（存储复制是昂贵的，但是FCI是必须的。AG不需要来自独立实例的共享存储，并且您可以使用文件共享见证进行仲裁，从而有可能消除对共享存储的需求）

Windows故障转移群集中的两个（或更多）服务器，SQL Server作为群集实例

1. 什么样的工作量？“取决于”-但是，对于需要在数据中心具有高可用性的本地应用程序的在线应用程序，这很有用。您可以防止一台机器或一个操作系统发生故障。登录，作业，新数据库，维护等都自动保持同步，因为它是一个群集，其中两个节点完全相同，共享相同的存储，因此它们具有所有相同的系统数据库。故障转移的速度非常快，但是发生故障转移时，仍然有一些麻烦，看起来像是SQL Server重新启动。

2. 缺点/单点故障是您的存储及其所有组件。SAN供应商总是说“ SAN不会失败”，但是存储区域网络中有很多活动部件，正如我在此处写的博客所述，它们可以做到。另外-您要为一台辅助服务器付费，该服务器除了闲逛并等待之外什么也不能做。.现在，您可以执行主动/主动/多节点并具有两个可以在任一方向进行故障转移并使用第二个节点的主动实例。

3. 自动故障转移？“最”自动的。无需见证人，这是一个集群。这是群集的工作，以使其尽可能无缝。现在，使用其中的任何一种，当发生故障转移时，您都会“感觉”到它，因为SQL必须启动或必须指向连接。在这种情况下，您基本上会感觉像是重新启动SQL，DB重新启动并运行recovery / etc。

如果我的客户在本地数据中心的高可用性环境中说“我想完全处理所有数据库，所有登录信息等”，因为我对停机的容忍度非常低，我会考虑故障转移群集实例（尽管您提到的最后一个选择是强大的竞争者，除了必须承担一些管理开销外）。我可能会做一个本地FCI和一个AG异步辅助服务器，以防止站点故障或SAN故障。

两个（或多个）SQL Server实例保持最新的事务复制

1. 什么样的工作量？老实说，在很多情况下，我都不愿将高可用性或灾难恢复作为首选。确保不在SQL 2012中。但是从根本上来说，如果必须去一个没有关闭的数据中心，不能使用AG（可能是一个域问题导致您无法使用AG所需的Windows群集），这很好。在SQL Server标准中可以复制，但不能复制AG，但是您仍然希望具有在辅助端读取并异步的功能。
2. 缺点/顾虑-它是复制项。它有开销，它可能不同步，您可能会在源代码方面产生性能问题，等等。
3. 自动故障转移 -否。您必须自己进行管理。通过CNAME指向一个或另一个，理论上您可以编写自己的过程来做到这一点，但是开箱即用？注意这里。

SQL Server可用性组中的两个（或更多）SQL Server，以同步提交模式配置

这就是我最近一直在帮助人们实现的功能，尽管有时我仍会去集群化。

1. 什么样的工作量？当我拥有一组易于管理的数据库来保持同步，并且确保作业，登录名，新数据库等保持同步的资源和时间时，这非常好（尽管SQL Skills团队为为您自动化其中的一部分，使其更加强大。当我想让事情完全分开时，我喜欢这样。我可以防止出现硬件问题，操作系统问题，SQL安装问题，修补问题和SAN /存储问题。我还受益于拥有一个辅助服务器（如果我想为其支付企业许可证）的能力，可以成为我可以读取，备份等的活动辅助服务器。此外，将来我可以添加第三个在远程站点异步并具有故障转移/ DR的辅助节点。
2. 缺点/许可许可，副本的最大数量，利用某些最大利益（活动的辅助）的许可成本，需要企业，需要的存储量是集群的两倍。
3. 自动故障转移 -是的。这可能发生在见证程序设置中，并且您的应用程序开发人员可以连接到侦听器而不是节点，因此故障转移发生在侦听器指向的地方，您应该在那里就可以了。所以是的，您可以在这里-并且应该-但当然您应该对其进行良好的测试。

摘要

HA和DR不同。这些技术可以帮助提供这两种技术。高可用性（对我而言）意味着，如果一台机器发生故障，您可以快速恢复，并且恢复点目标和恢复时间目标很短。那就是集群和同步AG。

灾难恢复是“即使在高可用性解决方案中出现故障也可以起床。对我来说，当您转到另一个数据中心，进行镜像甚至复制时，可能是AG。

考虑共享的内容也很重要。

故障转移群集使用两个或多个共享一个磁盘阵列的服务器节点。如果磁盘阵列出现故障，则无论有多少服务器节点，您都将失去服务。如果该磁盘阵列所在的服务器机房着火或泛洪，则您将失去服务。

AlwaysOn可用性组和数据库镜像是“不共享”的群集技术。该数据库位于多台服务器中的多个磁盘阵列上。如果您拥有良好的网络链接，则可以在多个服务器机房中使用多个服务器，从而防止火灾和洪水。

仅出于完整性考虑，可以选择使用普通的旧镜像。此处的优点包括拥有数据库的两个副本，而没有使用可用性组的复杂性，并且不需要共享存储来进行故障转移群集。缺点虽然不大，但不建议使用镜像。

带有镜像的故障转移时间约为10秒，尽管应用程序代码需要能够重试故障转移时发生的任何事务。