SQL Server 自动故障切换：工作原理与配置指南

SQL Server 中的自动故障切换是什么

当数据库服务器宕机时，每一秒停机都至关重要。SQL Server 中的自动故障切换是一种高可用性（HA）功能，当主服务器发生故障时，它会自动将同步的辅助副本提升为主角色，无需任何手动步骤。

它会将应用程序流量无缝重定向到新的主副本，通常在同步提交配置下运行以防止数据丢失。

如果主服务器遇到严重错误（如硬件崩溃、断电或服务故障），故障转移集群会自动检测问题并将辅助副本提升为新的主副本。

SQL Server 中自动故障切换如何工作

自动故障切换依赖于两个在后台持续运行的关键机制：健康监控和数据同步。当故障发生时，该过程经过五个步骤：

1. 主副本正常运行。 主服务器照常处理应用程序的所有读写请求。
2. 数据复制到辅助副本。 事务发生时，数据实时发送到辅助副本。自动故障切换需要同步提交模式——这确保在主副本确认每个事务之前数据已写入辅助副本，从而防止数据丢失。
3. 集群检测到故障。 Windows Server 故障转移集群（WSFC）持续监控服务器健康状况。如果检测到严重问题（如网络中断或服务崩溃），它会将主副本标记为故障状态。
4. 辅助副本被提升为主副本。 集群将同步的辅助副本提升为主角色，并将其数据库联机以处理活动工作负载。
5. 应用程序自动重新连接。 通过可用性组侦听器连接的应用程序将经历短暂断开，然后自动路由到新的主副本——无需更改连接字符串。

SQL Server 中的自动故障切换技术

在 SQL Server 中实施自动故障切换有多种方式。选择正确的技术取决于您需要保护整个服务器实例还是特定数据库。

Always On 可用性组（AG）

这是 SQL Server 高可用的现代标准。它允许您故障切换一组特定数据库，而不是整个服务器实例。由于不需要共享存储，副本可以放置在不同的物理位置。

Always On 故障转移集群实例（FCI）

与可用性组不同，FCI 保护整个 SQL Server 实例。它依赖于共享存储——如 SAN 或存储空间直通（S2D）——如果活动节点发生故障，实例将移动到集群中的另一个节点。

数据库镜像

数据库镜像是一项传统功能，已被 Microsoft 弃用。它支持自动故障切换，但一次仅限单个数据库，并且缺乏现代 Always On 解决方案的灵活性和多副本支持。建议迁移到 Always On 可用性组。

故障切换技术对比

如何使用 Always On AG 在 SQL Server 中配置自动故障切换

在 SQL Server 中设置自动故障切换需要仔细规划。最常见的方法是使用 Always On 可用性组。以下是为您的环境做好准备的逐步指南。

步骤 1 – 配置 Windows Server 故障转移集群

Windows Server 故障转移集群（WSFC）是监控服务器健康的基础。在配置 SQL Server 之前先设置它。

• 在所有参与的服务器上安装 故障转移集群 功能
• 运行 验证集群 工具以确认您的网络和存储满足要求
• 在进入下一步之前完成集群设置

步骤 2 – 启用 Always On 可用性组

集群就绪后，在 SQL Server 中启用 Always On。

• 打开 SQL Server 配置管理器
• 右键单击 SQL Server 服务并选择 属性
• 转到 Always On 高可用性 选项卡并勾选启用框
• 重启 SQL Server 服务以使更改生效

步骤 3 – 添加辅助副本

使用 SQL Server Management Studio (SSMS) 创建新的可用性组并添加辅助服务器。

• 在 SSMS 中启动 新建可用性组 向导
• 在提示时添加辅助服务器作为副本
• 确保 SQL Server 服务账户具有跨所有节点通信的网络权限

步骤 4 – 将副本设置为同步提交

同步提交确保辅助副本与主副本完全同步——这是自动故障切换的要求。

• 打开 可用性组属性
• 将您希望参与自动故障切换的任何副本的 可用性模式 设置为 同步提交

步骤 5 – 启用自动故障切换

最后一步是切换故障切换模式，以便集群可以在无需等待手动输入的情况下采取行动。

• 在可用性组属性中，将 故障切换模式 设置为 自动
• 这允许集群在检测到故障时自行将辅助副本提升为主副本

简化、零停机的 SQL Server 自动故障切换

虽然 SQL Server 提供了高可用的原生工具，但在复杂或大规模基础设施中管理这些配置通常需要额外的支持。

与 Always On 可用性组不同，i2Availability 完全摆脱了 WSFC 集群依赖，消除了大规模 SQL Server 自动故障切换部署中的单点故障、资源争用和管理复杂性。

i2Availability 关键功能

1. 1. • 自动化 HA 保障： 通过多心跳线检测和节点与磁盘仲裁机制防止误切换和脑裂场景。支持自定义脚本实现自动服务启停，结合虚拟 IP 漂移实现亚秒级故障切换。
      • 零延迟复制： 使用字节级实时复制捕获所有写操作，使恢复点目标接近零。备用服务器上的数据无需恢复即可立即使用，并支持反向同步以实现快速业务回退。
      • 优化的数据传输： 通过多级压缩和多线程并行处理减少带宽使用，并过滤非关键文件以优先保障业务数据。还支持带宽控制和断点续传以应对不稳定的网络条件。
      • 企业级数据安全： 数据传输使用 AES 和 SM4 加密保护。管理系统包含强密码策略和防暴力破解机制以保障访问安全。

这些功能协同工作，简化了高可用性管理，并在意外故障期间支持 SQL Server 环境的连续性。

SQL Server 自动故障切换最佳实践

设置自动故障切换只是工作的一部分——保持其可靠性需要持续关注。以下是需要遵循的关键实践：

1. 监控网络延迟： 同步提交模式意味着每个事务必须在辅助副本上确认后主副本才能继续。副本之间的慢速或不稳定连接将直接影响主数据库性能。

• • 在所有副本之间使用高速、低延迟的网络链路
  • 定期监控复制延迟以尽早发现问题

2. 配置仲裁见证： 故障转移集群需要多数投票才能保持在线。如果没有见证，失去一个节点可能导致整个集群脱机。

• • 设置 磁盘见证 或 云见证 以提供决胜投票
  • 这防止了两个节点都认为自己是主节点的”脑裂”场景

3. 定期测试故障切换： 未经测试的故障切换配置不可信赖。在维护窗口期间安排定期手动故障切换，以验证过程是否有效以及应用程序是否按预期重新连接。
4. 保持硬件和软件一致： 您的辅助副本应在 CPU、内存和 SQL Server 补丁级别方面与主副本匹配。如果辅助副本性能不足，在故障切换后可能难以处理完整生产负载。
5. 监控事务日志增长： 在同步提交模式下，如果辅助副本不可用，主副本上的事务日志将持续增长——因为日志截断会等待辅助副本确认已接收数据。如果不加以控制，这可能会填满主服务器上的磁盘空间。

• • 为事务日志使用量设置告警
  • 如果辅助副本长时间离线，制定应对计划

结论

SQL Server 中的自动故障切换是保护数据库环境免受意外停机的最有效方式之一。通过了解其工作原理——从健康监控和同步复制到自动副本提升——您可以构建一个无需等待人工干预即可响应故障的配置。

Always On 可用性组仍然是大多数环境的推荐方法，在配置同步提交模式时提供灵活的副本放置、可读辅助副本和可靠的自动故障切换。遵循本指南中涵盖的最佳实践——如定期测试故障切换、监控日志增长以及在副本之间保持一致的硬件——将有助于保持您的配置长期可靠。

对于管理复杂或大规模基础设施的组织，像 i2Availability 这样的专用解决方案可以通过简化 HA 管理、减少配置开销以及在 SQL Server 环境中提供额外的保护层来进一步推进这一目标。