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

SQL Server 故障转移群集实例 (FCI)

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

报道呢？ 无，NULL，不存在。故障转移集群实例有一个主动节点传递包含该实例、VNN 等的集群组，而所有其他节点都是被动的，处于空闲状态（就当前集群组而言）并等待故障转移。

发生故障转移时会发生什么？ FCI 的停机时间将取决于被动节点获取群集资源并使 SQL Server 实例处于运行状态所需的时间。这通常是最小的时间。

任何客户端抽象？ 是的，这将与故障转移群集实例的虚拟网络名称一起内置。这将始终指向当前提供 SQL Server 群集资源的活动节点。

AlwaysOn 可用性组

什么是高度可用的？ 可用性组在这里将成为高可用性的逻辑包含，而可用性组由许多数据库和一个虚拟网络名称（侦听器，可选的群集资源）组成。值得注意的是，登录和 SQL Server 代理作业等服务器对象不会成为 HA 解决方案的一部分，需要特别考虑以确保通过可用性组正确实施这些对象。不是一个过度负担的要求，但需要照顾。

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

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

任何客户端抽象？ 是的，您可以选择配置 AlwaysOn 可用性组侦听器。这基本上只是一个指向当前主副本的虚拟网络名称（通过 WSFC 可以看出是 AG 的集群组中的集群资源）。这是转移您的报告工作负载的关键部分，以及在您想要重定向 ReadOnly 流量的任何服务器上设置只读路由列表（这是通过连接字符串设置的，使用 .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 重新启动并运行恢复/等。

如果我有一个客户在本地数据中心的高可用性环境中说“我想完全使用所有数据库、所有登录等”，因为我对停机时间的容忍度非常低，我会考虑故障转移集群实例（尽管你提到的最后一个选项是一个强有力的竞争者，除了必须做一些管理开销）。我可能会做一个本地 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。

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

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

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

AlwaysOn 可用性组和数据库镜像是一种“无共享”集群技术。该数据库存在于多个服务器中的多个磁盘阵列上。如果您有良好的网络链接，那么多个服务器可以位于多个服务器机房中，从而保护您免受火灾和洪水的侵袭。

为了完整起见，可以选择使用普通的旧镜像。此处的优势包括拥有两个数据库副本，而无需使用可用性组的复杂性，并且无需共享存储来进行故障转移群集。缺点虽然很轻微，但不推荐使用镜像。

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