集群与事务复制与可用性组

Question

假设您需要确保依赖 SQL Server 2012 作为其数据库后端的应用程序全天候可用，即使一台服务器出现故障。

作为开发人员而不是 DBA，我很难理解何时使用哪种场景来实现故障转移/高可用性：

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

这些场景中的哪一个适用于什么样的工作负载，以及这些场景可以处理什么样的故障/中断？它们甚至具有可比性/可交换性吗？

Answer 1

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

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 集群组中的集群资源）。这是转移报告工作负载以及在要重定向只读流量的任何服务器上设置只读路由列表的关键部分（这是通过连接字符串设置的，使用 .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 不需要来自独立实例的共享存储，您可以使用文件共享见证进行仲裁，从而可能消除对共享存储的需要）

Answer 2

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。

Answer 3

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

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

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

Answer 4

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

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