1. 介绍 SQL Server 总是在
1.1什么是 SQL Server 始终开启？
SQL Server Always On 是微软推出的全面高可用性和灾难恢复解决方案，该方案于 2019 年推出。 SQL Server 2012 年。它代表着对数据库镜像和日志传送等先前技术的重大进步，确保了对数据的持续访问，同时最大限度地减少了停机时间和数据丢失。
1.2 企业为何需要始终在线的解决方案
在当今的数字经济中，数据库停机时间直接转化为……ost 收入损失、声誉受损和监管合规问题。企业需要高可用性解决方案，以确保近乎持续的正常运行时间，同时抵御各种故障情况。
传统的备份和恢复流程已无法满足现代企业的需求。当关键数据库发生故障时，企业无法承受从备份恢复所需的数小时时间。Always On 解决方案提供自动故障转移功能，可在数秒或数分钟内恢复服务，而非数小时，从而显著降低系统故障的影响。
除了基本可用性之外，企业还需要将读取密集型工作负载从生产数据库卸载，在不停机的情况下执行维护，并防止站点级灾难。 SQL Server Always On 通过统一的架构满足所有这些要求，该架构可以从小型部署扩展到全球分布式系统。
1.3 关键概念：RTO、RPO、HA 和 DR
恢复时间目标 (RTO) 定义了故障发生后可接受的最大停机时间——数据库必须多快恢复在线。
恢复点目标 (RPO) 定义了以时间为单位的最大可接受数据丢失量——企业能够承受丢失多少近期提交的数据。
高可用性 (HA) 专注于最大限度地减少同一数据中心内因硬件故障或软件崩溃等常规故障造成的停机时间。
灾难恢复（DR） 灾难恢复 (DR) 旨在应对影响整个站点的灾难性事件，并在地理位置不同的位置维护数据副本。高可用性 (HA) 侧重于最大限度地减少停机时间，而灾难恢复 (DR) 则侧重于确保在重大事件期间的数据保护和业务连续性。
SQL Server Always On 在单一统一架构中同时支持高可用性 (HA) 和灾难恢复 (DR)。同步提交模式可实现 RPO = 0，并可通过自动故障转移实现接近零的恢复时间目标 (RTO)；异步提交模式可接受潜在的数据丢失，以换取更低的远程站点延迟影响。
1.4 始终在线的解决方案
SQL Server Always On 提供三种部署选项，每种选项都适用于不同的可用性和基础架构要求。本指南涵盖所有三种选项：
- Always On 可用性组 (AG)： 无需共享存储即可实现数据库级高可用性和灾难恢复。
- Always On 故障转移集群实例 (FCI)： 利用共享存储实现实例级高可用性。
- AG + FCI 组合： 结合实例级和数据库级故障转移的双层保护，实现最大程度的恢复能力。
2. Always On 可用性组
Always On 可用性组 (AG) 是一个数据库级别的高可用性和灾难恢复解决方案，它通过连续事务日志传送将一组用户数据库复制到最多八个辅助副本。
2.1主要功能
- 数据库级故障转移：单个数据库或数据库组可以独立于其他因素发生故障转移。 SQL Server 实例;
- 企业版最多支持 9 个副本（1 个主副本，8 个辅助副本）；
- 同步提交模式可实现零数据丢失；异步提交模式适用于远程灾难恢复副本；
- 当主节点不可用时，同步副本自动故障转移；
- 用于卸载报表和备份工作负载的可读辅助副本；
- 可用性组监听器提供一个单一的连接端点，该端点会自动路由到当前主节点。
2.2 实施步骤
- 准备 Active Directory 服务帐户并配置所有节点上的权限；
- 在所有参与服务器上安装并验证 Windows Server 故障转移群集；
- 安装 SQL Server 在每个节点上作为独立实例，使用一致的路径和设置；
- 通过以下方式启用“始终在线可用性组”功能 SQL Server 配置管理器或 PowerShell；
- 将数据库设置为完整恢复模式，并进行完整备份和日志备份；
- 创建可用性组，添加副本，并配置可用性和故障转移模式；
- 使用自动种子或手动备份和恢复来为辅助副本添加种子；
- 创建可用性组监听器并验证客户端连接。
如需完整的逐步操作指南，请参阅我们的 始终在线可用性组完整指南.
2.3 最适合
- 需要零数据丢失和自动故障转移的关键任务数据库；
- 需要可读辅助数据进行报告或备份卸载的工作负载；
- 跨多个站点的灾难恢复部署；
- 没有现有共享存储基础设施的环境。
2.4专业人士
- 无需共享存储——每个副本都使用独立的本地存储；
- 在单一配置中同时支持高可用性和灾难恢复；
- 易于阅读的辅助文档可以减轻主要文档的工作量；
- 数据库级别的粒度允许为每个数据库组设置不同的故障转移策略。
2.5 缺点
- 要获得完整功能集，需要企业版（标准版支持基本 AG，但有诸多限制）；
- 同步提交模式会增加与网络往返时间成正比的写入延迟；
- 登录信息、SQL Agent 作业和链接服务器需要手动同步。 SQL Server 2019 年及以前；
- 所有副本必须位于同一 Windows Server 故障转移群集的节点上。
2.6参考
- 微软官方文档： 什么是 Always On 可用性组？
- 微软官方文档： 获得 Started 与 Always On 可用性组
3. Always On 故障转移集群实例
Always On 故障转移集群实例 (FCI) 通过运行单个实例提供实例级高可用性 SQL Server 该实例跨多个共享同一存储的物理节点运行。当活动节点发生故障时， SQL Server 备用节点上的实例会自动恢复。tarted，使客户端应用程序能够透明地完成过渡。
3.1主要功能
- 实例级故障转移：实例上的所有数据库作为一个整体一起发生故障转移；
- 所有节点均可访问的共享存储（存储区域网络 (SAN)、iSCSI、存储空间直连或 SMB）；
- 虚拟网络名称和虚拟 IP 地址提供稳定的连接端点，无论哪个节点处于活动状态；
- Windows Server故障转移群集管理节点运行状况监控、仲裁和故障转移编排；
- 支持主备、主主、N+1 和 N+M 节点配置类型。
3.2 实施步骤
- 为所有集群节点配置和附加共享存储；
- 安装故障转移集群功能并验证集群配置；
- 创建 Windows Server 故障转移群集并配置仲裁；
- 运行 SQL Server 安装时选择故障转移集群选项，并指定虚拟网络名称和共享存储路径；
- 向其中添加其他节点 SQL Server 故障转移集群实例；
- 通过测试节点间的手动故障转移来验证故障转移行为。
如需完整的逐步操作指南，请参阅我们的 SQL Server 故障转移集群完整指南.
3.3 最适合
- 具有现有共享存储基础设施（SAN 或 iSCSI）的环境；
- 需要实例级故障转移且所有数据库必须同时发生故障转移的应用；
- 在客户透明度至关重要且不允许应用程序端进行任何更改的情况下；
- 优先考虑单实例故障转移模型简易性的组织。
3.4专业人士
- 实例级自动故障转移，无需客户端重新配置；
- 无数据复制开销——所有节点访问相同的存储；
- 所有数据库同时发生可预测的故障转移行为；
- 支持灵活的节点配置（Active/Active、N+1、N+M），以优化硬件利用率。
3.5 缺点
- 除非存储本身具有冗余性，否则共享存储存在潜在的单点故障风险；
- 只有一个节点运行 SQL Server 同时进行——辅助节点上没有读取负载均衡；
- 不与可用性组配合使用，则没有内置的灾难恢复功能；
- 共享存储基础设施增加了 cost 与 AG 相比，其复杂性更高。
3.6参考
- 微软官方文档： Always On 故障转移集群实例（SQL Server)
4. 将可用性组与故障转移群集实例结合使用
对于既需要实例级保护又需要数据库级保护的组织而言， SQL Server 支持 host在故障转移集群实例 (FCI) 上部署可用性组副本。在此配置中，每个 FCI 节点都充当单个可用性副本，因此 FCI 故障转移对可用性组是透明的，而可用性组故障转移则提供跨站点的数据库级保护。这种组合实现了……ost 提供全面的高可用性和灾难恢复保障 SQL Server.
4.1主要功能
- 两层故障转移：FCI 处理实例级节点故障；AG 处理站点级或副本级故障；
- 无论 FCI 包含多少个节点，每个 FCI 在可用性组中都算作一个副本；
- FCI-host按照标准 FCI 要求，ed 副本仍然需要共享存储；
- AG 复制品 hostFCI 仅支持手动故障转移——FCI-h 不支持自动故障转移。osted 复制品；
- 独立实例可以与 FCI-h 一起参与同一个可用性组。osted 复制品。
4.2 实施步骤
- 按照标准 FCI 设置程序，独立部署和验证每个 FCI；
- 确保所有 FCI 节点和独立副本节点都属于同一个 Windows Server 故障转移群集；
- 在每个 FCI 实例上启用 Always On 可用性组功能；
- 确认没有单个 WSFC 节点会 host 在任何可能的 FCI 故障转移后，同一可用性组的两个副本；
- 创建可用性组，将 FCI 实例指定为副本，并为所有 FCI-h 配置手动故障转移模式。osted 复制品；
- 初始化辅助副本并配置可用性组监听器。
有关 FCI 设置详情，请参阅我们的 SQL Server 故障转移集群完整指南。有关可用性组 (AG) 设置的详细信息，请参阅我们的 Always On 可用性组完整指南。
4.3 最适合
- 需要防范单个节点故障和站点级灾难的关键任务环境；
- 已经运行 FCI 且需要添加跨站点灾难恢复功能的组织；
- 受监管行业，其中最高级别的数据保护和可用性服务水平协议是强制性的；
- 大规模部署中，实例级和数据库级故障转移策略必须共存。
4.4专业人士
- 最大程度的保护：节点故障由 FCI 处理，站点故障由 AG 处理；
- FCI 故障转移对可用性组是透明的——可用性组在 FCI 故障转移期间看不到任何副本更改；
- 灵活拓扑：混合 FCI-host同一可用性组中的 ed 副本和独立副本。
4.5 缺点
- FCI-hosted 副本仅支持手动 AG 故障转移——这些副本不支持自动 AG 故障转移；
- 需要仔细规划WSFC节点，以防止单个节点出现故障。ostFCI故障转移后创建同一AG的两个副本；
- 更高的基础设施 cost 运营复杂度高于 AG 或 FCI 单独运营的复杂度；
- 每个FCI组件仍然需要共享存储空间。
4.6参考
- 微软官方文档： 故障转移群集和 Always On 可用性组 (SQL Server)
- 微软官方文档： 什么是 Always On 可用性组？
- 微软官方文档： 获得 Started 与 Always On 可用性组
- 微软官方文档： Always On 故障转移集群实例（SQL Server)
5. 始终在线解决方案的比较
5.1 功能对比表
| 特性 | 可用性组 | 故障转移集群实例 | AG + FCI 联合 |
|---|---|---|---|
| 故障转移范围 | 数据库级 | 实例级 | 以上皆是 |
| 需要共享存储 | 没有 | 是 | 是的（针对FCI组件） |
| 数据复制 | 每个副本的日志记录 | 无（共享存储） | FCI之间的对数关系 |
| 自动故障转移 | 是的（同步副本） | 是 | FCI：是；AG：否 |
| 可读的二级 | 是 | 没有 | 是的（农业部分） |
| 灾难恢复 | 内建的 | 非内置 | 内建的 |
| 最大副本 | 9（企业） | 无 | 9（企业） |
| 基础设施的复杂性 | 中 | 中 | 高 |
| 成本 | 较低（无需SAN） | 更高（需要SAN） | 最高 |
5.2 选择您的始终在线解决方案
Star与您的存储基础架构配合使用：如果您没有现有的共享存储，可用性组是自然之选，并且ost cost-同时实现高可用性和灾难恢复的有效途径。如果您已经运行SAN环境并且需要实例级故障转移，FCI是更简单的选择——但如果将来需要跨站点灾难恢复，则需要计划稍后添加AG。
只有当您确实需要两层防护，并且具备应对日益复杂情况的运行成熟度时，才选择 AG + FCI 组合。需要记住的关键限制是 FCI-hosted AG 副本不支持自动 AG 故障转移，因此这种拓扑结构需要手动干预才能实现可用性组级别的故障转移。
对于米ost 对于当今的全新部署，Always On Availability Groups 是推荐的解决方案。tar关键点：它同时涵盖了高可用性和灾难恢复，不需要共享存储，并且支持可读辅助存储——这是 FCI 单独无法比拟的功能。
6. 最佳实践 SQL Server 始终在线解决方案
6.1 规划设计
- 在选择始终在线解决方案之前，先明确 RTO 和 RPO 要求——这些 tar获取直接判断同步提交模式还是异步提交模式合适，以及自动故障转移是否可行。
- 调整辅助副本的大小，使其能够在故障转移事件期间处理主副本的全部工作负载，包括峰值负载场景。
- 对于 AG 部署，应将同步副本放置在同一数据中心或低延迟网络中，以最大程度地减少写入延迟的影响。对于地理位置较远的灾难恢复副本，则应保留异步模式。
- 设计法定人数时，应使用奇数票。对于双节点集群，添加文件共享或云见证作为第三票，以防止脑裂情况的发生。
- 对于多子网部署，请仔细规划网络拓扑。每个子网都需要自己的监听器 IP 地址，客户端需要在其连接字符串中设置 MultiSubnetFailover=True。
6.2 实施指南
- 使用一致的 SQL Server 所有副本的版本、版本号和累积更新级别。混合的补丁级别可能会导致故障转移期间出现意外行为。
- 配置专用的网络接口，用于集群心跳流量，与应用程序流量分开。
- 启用初始数据库同步的自动种子数据 SQL Server 2016 年及以后版本——它消除了手动将备份复制到辅助副本的需要。ost 场景。
- 对于 AG + FCI 拓扑结构，每次 FCI 节点配置更改后，都要验证是否存在单个 WSFC 节点最终处于 h 状态的情况。ost创建同一可用性组的两个副本。
- 一律使用 SQL Server 使用 Management Studio 或 Transact-SQL 管理可用性组故障转移——切勿直接使用故障转移集群管理器，因为它不知道 AG 同步状态，可能会导致长时间停机或数据丢失。
6.3 监控维护
- 使用可用性组仪表板定期监控同步运行状况、发送队列和重做队列。 SQL Server 管理工作室或动态管理视图 (DMV)。辅助服务器上不断增长的重做队列表明存在 I/O 瓶颈，这将延迟故障转移恢复。
- 在辅助副本上运行 DBCC CHECKDB，以将完整性检查从主副本卸载。请参阅我们的 DBCC CHECKDB 指南 以获取详情。
- 在断裂前， SQL Server 使用滚动升级进行补丁：首先修补辅助副本，执行计划内的手动故障转移到已修补的辅助副本，然后再修补原主副本。这样可以将停机时间限制在单次故障转移的持续时间内。
- 定期在非生产环境中测试故障转移。未经测试的自动故障转移并非可靠的恢复策略。
- 使用以下方式配置可用性组运行状况更改、副本角色转换和同步故障的警报 SQL Server 代理或专用监控工具，例如 SQL Server 性能监视器.
7。 常问问题
问：什么是 SQL Server 始终开启？
A: SQL Server Always On 是微软于 2019 年推出的高可用性和灾难恢复平台。 SQL Server 2012 年。它包含两项技术——Always On 可用性组和 Always On 故障转移集群实例——在硬件、软件或站点发生故障时，可提供自动故障转移、数据冗余和对数据库的持续访问。
问：Always On可用性组和故障转移群集实例之间有什么区别？
答：可用性组 (AG) 在数据库级别运行，通过日志传送将数据复制到独立的辅助副本，并且不需要共享存储。故障转移集群实例 (FCI) 在实例级别运行，需要所有节点均可访问的共享存储，并将所有数据库作为一个整体进行故障转移。AG 支持可读辅助副本和内置灾难恢复功能；FCI 则不支持。
问：Always On可用性组需要共享存储吗？
答：不。每个可用性组副本都在本地存储上维护着各自独立的数据库副本。只有当您使用故障转移群集实例来……时，才需要共享存储。ost AG 复刻品。
问：我可以使用 Always On 功能吗？ SQL Server 标准版？
A: SQL Server 标准版支持基本可用性组tar与 SQL Server 2016 年版本，但存在诸多限制：每个可用性组 (AG) 仅限一个数据库，最多两个副本，且不支持可读辅助数据库。标准版 FCI 不受这些限制。企业版则需要 Always On 的完整功能。
问：可用性组中最多可以有多少个副本？
A: SQL Server 企业版最多支持九个副本：一个主副本和八个辅助副本。分布式可用性组可以将副本数量扩展到两个独立可用性组的 18 个副本。
问：FCI-h 可以吗？osted 副本是否使用自动 AG 故障转移？
答：不。当可用性副本处于高可用性状态时，ost在故障转移群集实例上，该副本不支持自动可用性组故障转移。所有涉及 FCI-h 的可用性组故障转移。ost复制品需要人工干预。
问：同步提交模式和异步提交模式有什么区别？
答：同步提交模式要求主库等待从库完成日志记录的加固后再提交，从而确保零数据丢失（RPO = 0）。ost 增加写入延迟。异步提交模式允许主节点无需等待即可提交，从而降低延迟，但如果主节点在从节点接收到所有日志记录之前发生故障，则存在数据丢失的风险。本地高可用性副本应使用同步模式，远程灾难恢复副本应使用异步模式。
问：一个 SQL Server Always On 故障转移方案？
答：在正常情况下，同步可用性组副本的自动故障转移通常会在 30 秒内完成。FCI 故障转移通常需要 20 到 60 秒，具体取决于数据库恢复时间。实际持续时间取决于工作负载、数据库大小以及 WSFC 中配置的运行状况检查超时设置。
问：故障转移期间客户端连接会发生什么情况？
答：发生故障转移时，现有连接将被断开。使用可用性组侦听器并包含连接重试逻辑的应用程序会在故障转移完成后自动重新连接到新的主节点。在连接字符串中添加 `MultiSubnetFailover=True` 可以提高多子网部署中的重新连接速度。
问：我该如何申请 SQL Server 在始终在线的环境下，如何以最小的停机时间完成补丁程序？
答：采用滚动升级：先修补备用副本，然后执行计划内的手动故障转移到已修补的备用副本，最后修补原主副本。这样可以将停机时间限制在单次计划故障转移的持续时间内——通常不到一分钟。
问：我可以将 Always On 可用性组与故障转移群集实例结合使用吗？
A：是的。你可以……ost 在 FCI 实例上部署 AG 副本，以实现实例级和数据库级故障转移保护。每个 FCI 算作一个 AG 副本。这种拓扑结构需要仔细规划 WSFC 节点，以确保没有单个节点发生故障。ost在任何可能的 FCI 故障转移之后，都会出现同一 AG 的两个副本。
问：如果我的数据库在 Always On 环境中损坏，我应该怎么办？
答：首先，检查损坏是存在于所有副本还是仅存在于主副本。如果存在健康的备用副本，请立即故障转移到该备用副本。如果所有副本都存在损坏，请从干净的备份中恢复。定期在备用副本上运行 DBCC CHECKDB 命令，以便及早发现损坏。如果备份也受到影响，则需要进行专门的故障转移。 SQL Server 数据恢复工具 作为最后的手段，可以尝试从损坏的 MDF 文件中提取数据。
问：Always On 可用性组与旧版本相比有何不同？ SQL Server HA解决方案？
A：AG取代了诸如以下旧技术： 原木运输 以及 复制日志传送需要手动故障转移，且不具备自动角色转换功能；复制的设计目标是数据分发而非高可用性。AG 提供自动故障转移、同步提交实现零数据丢失以及可读的辅助副本——这些都是上述技术无法比拟的。
8. 结论
SQL Server Always On 提供了一个灵活的企业级平台，用于实现高可用性和灾难恢复。Always On Availability Groups 是 m 的理想选择。ost 现代部署：它无需共享存储，支持可读辅助存储，并在单一配置中同时处理本地高可用性和跨站点灾难恢复。当实例级故障转移和现有共享存储基础架构是主要需求时，故障转移集群实例仍然是一个可靠的选择。结合这两种技术可提供最全面的保护——在关键时刻。ost 基础设施投资更大，运营更复杂。
无论选择哪种解决方案，基本原理都相同：首先定义您的恢复时间目标 (RTO) 和恢复点目标 (RPO) 要求，然后围绕这些要求设计拓扑结构。 tar定期获取并测试故障转移方案。一个经过充分测试且部署完善的 Always On 解决方案，能够在生产环境发生故障时实现可预测的恢复。
关于作者
袁盛 是一位高级数据库管理员 (DBA)，拥有超过 10 年的 SQL Server 环境和企业数据库管理。他成功解决了金融服务、医疗保健和制造等行业的数百个数据库恢复场景。
袁专长于 SQL Server 数据库恢复、高可用性解决方案和性能优化。他拥有丰富的实践经验，包括管理多TB数据库、实施Always On可用性组以及为关键业务系统开发自动备份和恢复策略。
通过他的技术专长和实践方法，袁致力于创建全面的指南，帮助数据库管理员和 IT 专业人员解决复杂的 SQL Server 高效应对挑战。他始终掌握最新 SQL Server 版本和微软不断发展的数据库技术，定期测试恢复场景以确保他的建议反映现实世界的最佳实践。
有关于的问题 SQL Server 恢复或需要额外的数据库故障排除指导？袁欢迎 反馈和建议 用于改进这些技术资源。