SQL Server HA vs. DR - 选择哪一个 - 清单和指南

业务连续性的支柱

在现代企业中，数据是运营的命脉，其持续可用性是不可谈判的。对于依靠Microsoft SQL Server的组织，高可用性（HA）和灾难恢复（DR）构成了弹性数据策略的双支柱。尽管经常一起讨论，但它们解决了根本不同的失败，并具有不同的目标，范围和机制。一个全面的计划不是要选择一个计划。这是关于智能分层的，以创建一个深入的防御架构，可以承受从次要服务器故障到灾难性数据中心损失的故障。

高可用性（HA）：不间断服务的任务

高可用性是一组技术和建筑原则，重点是一个单一的主要目标：通过消除特定物理位置内的单个失败来确保服务的连续运行。 HA的核心目标是服务可用性。它旨在使数据库和应用程序通过局部故障在线访问，并且任何中断都不存在。 HA解决方案的基本意图是面对共同的组成部分失败， *保留服务 *。

真正的HA解决方案的定义特征是它依赖自动化的快速故障转移。当在主要组件中检测到故障时，系统会自动，并且没有人类干预将操作重定向到冗余，备用组件。该过程设计为非常快速，通常以几秒钟的速度测量，以满足正常运行时间的严格服务水平协议（SLA）。

灾难恢复（DR）：生存灾难的策略

灾难恢复涵盖了整体策略，政策和程序，用于重新建立关键技术基础设施和系统，这使灾难性事件使主要的运营现场无法使用。 DR的主要目标是服务连续性 - 从次级独立的位置恢复业务功能的能力。与旨在防止停机时间的HA不同，DR接受停机时间将发生，并着重于最大程度地减少其持续时间和影响。 DR计划的核心意图是 *保留数据 *并恢复大量停电后提供服务的能力。

调用DR计划的机制通常是手动或精心策划的故障转移。失败到另一个地区的决定是一个重大的业务决策，具有广泛的影响，因此，它很少完全自动化。此过程本质上比HA故障转移慢，并在几分钟或小时内测量恢复时间。

高可用性（HA）

目标：不间断的服务

HA专注于消除单个位置内的单个故障点。它提供自动化的快速故障转移，可在局部故障（例如服务器崩溃或操作系统故障）等局部故障期间保持服务。

• 范围：本地（同一数据中心）
• 目标：保留服务
• 故障转移：自动和快速（秒）
• 类比：游戏中的替补四分卫。

灾难恢复（DR）

目标：生存灾难

DR是在灾难性事件发生后重新建立系统的策略，使主要站点无法使用。它专注于从次级，地理独立的位置恢复服务。

• 范围：地理（不同地区）
• 目标：保留数据
• 故障转移：手动和较慢（分钟/小时）
• 类比：撤离到指定的庇护所。

翻译业务需求：RTO和RPO

在选择技术之前，您必须定义业务对停机时间和数据丢失的容忍度。这两个指标RTO和RPO将控制您的HADR策略中的所有决定。

更多阅读：SQL Server 2022升级：固定SQL 2016的性能降级

恢复点目标（RPO）

“我们可以承受多少数据？”

RPO测量最大可接受的数据丢失量，该数据丢失是从失败后退的时间内测量的。接近零的RPO需要同步数据复制，而较高的RPO可以使用异步方法（如日志运输或备份）来满足。

恢复时间目标（RTO）

“我们必须多快回到网上？”

RTO定义了最大可接受的停机时间。接近零的RTO要求使用完全自动化的故障转移解决方案，而较高的RTO允许手动恢复程序。

RTO/RPO技术

SQL Server HADR技术投资组合

SQL Server提供了丰富的技术组合。了解每种体系结构和用例是必不可少的。

始终关注可用性组（AGS）

总理集成的HADR解决方案，在数据库级别提供保护。它的共享架构为HA（通过同步提交）和DR（通过异步提交）提供了令人难以置信的灵活性。

始终在故障转移群集实例（FCIS）上

传统方法在服务器实例级别提供保护。 FCIS依靠共享存储，是纯本地HA解决方案，可保护整个实例，包括系统数据库和SQL代理作业。

日志运输

简单，可靠且具有成本效益的DR解决方案。它通过自动备份主服务器上的事务日志并在辅助服务器上还原它们来起作用。这是具有可配置RPO的手动故障转移过程。

备份和还原

任何策略的基础部分。尽管复制可以防止基础架构故障，但只有备份中的时间点还原才能从逻辑数据损坏或人为错误中恢复。

建筑师的决策矩阵

使用此清单快速评估哪些解决方案与您的技术，业务和财务限制保持一致。

过滤器：

全部
哈
博士

所有版本
企业
标准

数据保护的物理学：网络延迟

同步复制和异步复制之间的选择是零数据丢失与应用程序性能之间的直接权衡，这是完全受网络延迟管理的权衡。

同步与异步提交模式

同步提交（HA）

理想延迟：<5ms

1
客户发送提交

2
主要将日志发送到次要

3
次要硬登录和ack

4
主要确认对客户的承诺

结果：零数据丢失，但交易延迟增加。

异步提交（DR）

耐高潜伏期

1
客户发送提交

2
主要确认对客户的承诺

3
主将日志发送到次要（不等待）

4
次要硬登日志以后

结果：最小的性能影响，但可能会导致数据丢失。

可用性经济学：SQL Server Edition支持

HADR体系结构的选择受成本的很大影响，该成本主要由SQL Server Edition决定。

按版本的关键HADR功能

导航异质性：支持混合配置

在理想的世界中，HADR拓扑中的所有服务器都是相同的。但是，诸如分阶段硬件刷新，软件升级和预算周期之类的实际现实通常会导致有关异质环境可行性的问题。了解混合SQL Server版本，版本和硬件的规则对于维护稳定且支持的解决方案至关重要。

混合SQL服务器版本和版本

微软的支持策略很明确：对于永久生产环境，单个AG或FCI中的所有实例都必须运行相同的主要版本和SQL Server版本。如果数据库使用仅企业功能，则从企业到标准的故障转移可能会导致故障。

关键的例外是在滚动升级期间。此过程允许临时的混合元素AG以最少的停机时间升级SQL Server。这是一个受支持的维护程序，而不是永久设计。从较旧版本到较新版本的故障转移是数据库格式的单向旅行。直到较旧的实例也升级后，您才会失败。

混合硬件配置

尽管在技术上进行了可能的情况，但强烈建议使用不同的硬件规格（CPU，内存，存储）来进行节点或FCI中的节点。整个系统的性能通常取决于其最弱的链接。

• 同步AGS：较慢的辅助复制品I/O将成为瓶颈，并直接降低主服务器上的每个写操作。
• 故障转移：如果新的主服务器功能较差，则应用程序性能将急剧降低，可能违反SLA。

最好的做法是确保所有潜在的主要节点具有相同或非常相似的硬件配置。

混合配置支持矩阵

主要考虑因素：混合/版本环境是维护的临时状态，而不是永久性设计。性能仅与集群中最弱节点一样可靠。

交互式决策树

选择正确的HADR解决方案可能很复杂。回答下面的问题，以根据您对恢复，范围和预算的特定需求获取个性化建议。

重新开始

常见的建筑模式

基于分析，出现了几种共同且有效的建筑模式，以满足不同的组织需求。

模式1：最大可用性和DR

“成本不是对象”模式

利用多站点的多区域分布式可用性组。通过将HA的局部同步AG与DR的地理复制异步Ag相结合，从而提供了最高的弹性水平。

要求：SQL Server Enterprise Edition。

模式2：成本优化的HA/DR

“标准版主力”模式

结合了用于本地HA的两节点故障转移群集实例（FCI）与远程DR的日志运输。这仅使用标准版功能提供了完整而强大的HA+DR解决方案。

要求：SQL Server标准版。

图案3：云杂种弹性

现代DR方法

将公共云（Azure，AWS）用作具有成本效益的DR网站。本地主服务器通过安全网络连接在可用性组中的基于云的辅助副本复制。

要求：SQL Server Enterprise或Standard（具有基本AGS）。

最终建议

HADR实现仅仅是开始。为了确保在调用时起作用，必须连续的文档，测试和监视循环。

• 记录所有内容：创建一个综合的DR计划，其中包括通信协议和分步程序，用于故障转移和故障。
• 测试，测试和重新测试：定期安排并执行DR测试，以验证您的RTO/RPO目标可以在实践中满足您的RTO/RPO目标。未经测试的计划只是一个假设。
• 剧烈监视：主动监测群集健康，AG同步状态和数据丢失滞后。使用DMV并配置警报在成为灾难之前捕获问题。

-- Check AG sync state and potential data loss
SELECT 
    replica_server_name, 
    database_name, 
    synchronization_state_desc, 
    synchronization_health_desc,
    last_hardening_lsn,
    log_send_queue_size,
    log_send_rate,
    redo_queue_size,
    redo_rate
FROM sys.dm_hadr_database_replica_states