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

#1 楼

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

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

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

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

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

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

AlwaysOn可用性组

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

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

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

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

事务复制

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

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

摘要

归结为以下几个问题（部分由企业）需要回答：


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

#2 楼

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




什么样的工作负载？ “取决于”-但是，对于需要在数据中心具有高可用性的本地应用程序的在线应用程序，这很有用。您可以防止一台机器或一个操作系统发生故障。登录，作业，新数据库，维护等都自动保持同步，因为它是一个群集，其中两个节点完全相同，共享同一存储，因此它们具有所有相同的系统数据库。故障转移的速度非常快，但是发生故障转移时，SQL Server仍然会出现重启的麻烦。
缺点/关注点-单点故障是您的存储及其所有组件。 SAN供应商总是说“ SAN不会失败”，但是存储区域网络中有很多活动部件，正如我在此处写的博客所述，它们可以做到。另外-您要为一台辅助服务器付费，该服务器除了闲逛并等待之外什么也不能做。.现在，您可以执行Active / Active / Multi-Node，并具有两个可以在任一方向进行故障转移并使用第二个节点的活动实例。
自动故障转移？ “最”自动的。无需见证人，这是一个集群。这是集群的工作，以使其尽可能无缝。现在，使用其中的任何一种，当发生故障转移时，您都会“感觉”到它，因为SQL必须启动或必须指向连接。在这种情况下，您基本上会感觉像是重新启动SQL，DB重新启动并运行recovery / etc。

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


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




什么样的工作负载？老实说，我不会在很多情况下将高可用性或灾难恢复作为首选。确保不在SQL 2012中。但是从根本上来说，如果您必须前往未关闭的数据中心，不能使用AG（这可能是一个域问题导致您无法使用AG所需的Windows群集），这很好。可以复制但不能复制AG的SQL Server标准中，但是您仍然希望能够在辅助端进行读取并实现异步。

缺点/问题-它是复制项。它有开销，它可能会不同步，您可能会在源端出现性能问题等。

自动故障转移-否。您必须自己进行管理。通过CNAME指向一个或另一个，理论上您可以编写自己的过程来做到这一点，但是开箱即用？在此处注意。


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



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



什么样的工作量？当我有一组易于管理的数据库来保持同步，并且资源和时间可以确保作业，登录名，新数据库等保持同步时，这非常好（尽管SQL Skills的团队在其中添加了很多功能）为您自动化其中的一部分，使其更加强大。当我想让事情完全分开时，我喜欢这样。我可以防止出现硬件问题，操作系统问题，SQL安装问题，修补问题和SAN /存储问题。我还受益于能够拥有辅助服务器（如果我想为其支付企业许可证费用）成为可以读取，备份等的活动辅助服务器的功能。此外，将来我可以添加第三个

缺点/问题许可，副本的最大数量，利用某些最大好处的许可成本（活动的辅助），需要企业，所需存储量是群集的两倍。

自动故障转移-是的。这可能发生在见证程序设置中，并且您的应用程序开发人员可以连接到侦听器而不是节点，因此故障转移发生在侦听器指向的地方，您应该在那里就可以了。因此，是的，您可以在此处-并且应该-但当然应该对其进行测试。

摘要

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

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

#3 楼

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

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

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

#4 楼

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

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