印刻数据库

外观

SQLServer Always On 故障处理 ​

Always On 故障概述 ​

Always On Availability Groups 是 SQL Server 2012 及以上版本提供的高可用解决方案，它通过将数据库副本部署在多个服务器上，实现自动故障检测和故障切换，确保数据库服务的高可用性。在 Always On 环境中，可能会遇到各种故障，如硬件故障、网络故障、软件故障等，需要 DBA 能够快速检测、诊断和处理这些故障，确保业务连续性。

Always On 故障类型 ​

  1. 主副本故障：

    • 主副本服务器硬件故障
    • 主副本服务器操作系统崩溃
    • 主副本 SQL Server 服务停止
    • 主副本网络连接故障

  2. 辅助副本故障：

    • 辅助副本服务器硬件故障
    • 辅助副本服务器操作系统崩溃
    • 辅助副本 SQL Server 服务停止
    • 辅助副本网络连接故障

  3. 可用性组故障：

    • 可用性组配置损坏
    • 可用性组元数据损坏
    • 可用性组故障转移失败

  4. 数据库故障：

    • 数据库文件损坏
    • 数据库事务日志损坏
    • 数据库一致性错误

故障检测与监控 ​

故障检测机制 ​

Always On Availability Groups 提供了内置的故障检测机制，主要通过以下方式实现：

  1. 心跳检测：

    • 副本之间定期发送心跳消息（默认每5秒）
    • 如果在指定时间内（默认30秒）没有收到心跳消息，则认为副本不可用
    • 可以通过 HEARTBEAT_TIMEOUT 参数调整心跳超时时间

  2. 连接检测：

    • 定期检测副本之间的数据库连接
    • 如果连接失败，则尝试重新连接
    • 可以通过 FAILURE_CONDITION_LEVEL 参数调整故障检测的敏感度

  3. 健康检测：

    • 监控 SQL Server 服务状态
    • 监控数据库状态
    • 监控系统资源使用率

故障监控工具 ​

  1. SQL Server Management Studio (SSMS)：

    • 查看可用性组的状态和健康情况
    • 查看副本的同步状态
    • 查看数据库的同步状态

  2. 复制监视器：

    • 监控可用性组的性能和状态
    • 查看故障转移历史记录
    • 配置告警

  3. 动态管理视图 (DMVs)：

    sql
    -- 查看可用性组状态
SELECT 
    ag.name AS availability_group,
    ag.state_desc AS ag_state,
    ar.replica_server_name,
    ar.availability_mode_desc,
    ar.failover_mode_desc,
    ar.primary_role_allow_connections_desc,
    ar.secondary_role_allow_connections_desc
FROM sys.availability_groups ag
JOIN sys.availability_replicas ar ON ag.group_id = ar.group_id;

-- 查看数据库副本状态
SELECT 
    db_name(drs.database_id) AS database_name,
    ar.replica_server_name,
    drs.synchronization_state_desc,
    drs.synchronization_health_desc,
    drs.database_state_desc,
    drs.is_failover_ready,
    drs.last_hardened_lsn,
    drs.last_redone_lsn,
    drs.last_sent_time,
    drs.last_received_time,
    drs.last_hardened_time,
    drs.last_redone_time,
    DATEDIFF(second, drs.last_sent_time, GETDATE()) AS sent_latency_seconds,
    DATEDIFF(second, drs.last_received_time, GETDATE()) AS received_latency_seconds,
    DATEDIFF(second, drs.last_redone_time, GETDATE()) AS redo_latency_seconds
FROM sys.dm_hadr_database_replica_states drs
JOIN sys.availability_replicas ar ON drs.replica_id = ar.replica_id;

-- 查看可用性组侦听器状态
SELECT 
    listener_id,
    group_id,
    dns_name,
    port,
    is_conformant,
    ip_configuration_string_from_cluster
FROM sys.availability_group_listeners;

  4. Extended Events：

    • 创建扩展事件会话，监控可用性组相关事件
    • 捕获故障转移事件、错误事件等
    sql
    -- 创建扩展事件会话监控 Always On 故障转移
CREATE EVENT SESSION [AlwaysOn_Failover_Monitor] ON SERVER 
ADD EVENT sqlserver.availability_group_lease_expired,
ADD EVENT sqlserver.availability_group_state_change,
ADD EVENT sqlserver.database_failover_group_lease_expired,
ADD EVENT sqlserver.database_mirroring_failover,
ADD EVENT sqlserver.database_mirroring_failover_lost_data,
ADD EVENT sqlserver.hadr_availability_group_failover_state_change,
ADD EVENT sqlserver.hadr_availability_replica_failover_state_change,
ADD EVENT sqlserver.hadr_database_failover_state_change
ADD TARGET package0.event_file(SET filename=N'C:\AlwaysOn_Failover_Monitor.xel')
WITH (MAX_MEMORY=4096 KB, EVENT_RETENTION_MODE=ALLOW_SINGLE_EVENT_LOSS, MAX_DISPATCH_LATENCY=30 SECONDS, MAX_EVENT_SIZE=0 KB, MEMORY_PARTITION_MODE=NONE, TRACK_CAUSALITY=OFF, STARTUP_STATE=ON);
GO

-- 启动扩展事件会话
ALTER EVENT SESSION [AlwaysOn_Failover_Monitor] ON SERVER STATE = START;
GO

故障切换操作 ​

自动故障切换 ​

当主副本发生故障时，如果满足以下条件，Always On Availability Groups 会自动执行故障切换：

  1. 至少有一个同步提交模式的辅助副本处于同步状态
  2. 故障转移模式设置为自动故障转移
  3. 故障检测机制确认主副本不可用

自动故障切换的过程如下：

  1. 检测到主副本故障
  2. 选择合适的辅助副本作为新的主副本
  3. 执行故障切换，将辅助副本提升为主副本
  4. 更新可用性组侦听器的路由
  5. 客户端重新连接到新的主副本

手动故障切换 ​

在某些情况下，可能需要执行手动故障切换，如：

  • 主副本需要维护或升级
  • 自动故障切换失败
  • 测试故障切换机制

手动故障切换分为两种类型：

  1. 计划内故障切换：

    • 主副本和辅助副本都处于正常状态
    • 执行同步故障切换，确保数据不丢失
    • 适用于主副本维护或升级场景
    sql
    -- 执行计划内故障切换
ALTER AVAILABILITY GROUP [YourAGName] FAILOVER;
GO

  2. 强制故障切换：

    • 主副本不可用或无法正常通信
    • 执行异步故障切换，可能会丢失数据
    • 适用于主副本故障且无法恢复的场景
    sql
    -- 执行强制故障切换（可能丢失数据）
ALTER AVAILABILITY GROUP [YourAGName] FORCE_FAILOVER_ALLOW_DATA_LOSS;
GO

故障切换注意事项 ​

  1. 数据一致性：

    • 计划内故障切换确保数据不丢失
    • 强制故障切换可能会丢失数据，需要谨慎使用
    • 在执行强制故障切换前，应评估数据丢失的影响

  2. 客户端连接：

    • 使用可用性组侦听器连接数据库，确保故障切换后客户端能够自动重新连接
    • 配置合适的连接超时时间和重试机制

  3. 应用程序兼容性：

    • 确保应用程序能够处理数据库连接中断和重新连接
    • 测试应用程序在故障切换后的行为

  4. 故障切换时间：

    • 计划内故障切换的时间通常较短（几秒到几十秒）
    • 强制故障切换的时间可能较长，取决于系统负载和数据库大小

故障恢复与修复 ​

主副本故障恢复 ​

当主副本发生故障并完成故障切换后，需要恢复原主副本并将其重新加入可用性组：

  1. 修复原主副本：

    • 修复硬件故障
    • 重建操作系统
    • 重新安装 SQL Server
    • 恢复数据库（如果需要）

  2. 将原主副本重新加入可用性组：

    • 将原主副本配置为辅助副本
    • 重新初始化数据库同步
    sql
    -- 将原主副本重新加入可用性组
ALTER AVAILABILITY GROUP [YourAGName] JOIN;
GO

-- 初始化数据库同步
ALTER DATABASE [YourDatabaseName] SET HADR AVAILABILITY GROUP = [YourAGName];
GO

辅助副本故障恢复 ​

当辅助副本发生故障时，需要恢复辅助副本并将其重新加入可用性组：

  1. 修复辅助副本：

    • 修复硬件故障
    • 重建操作系统
    • 重新安装 SQL Server
    • 恢复数据库（如果需要）

  2. 将辅助副本重新加入可用性组：

    • 将辅助副本配置为可用性组的成员
    • 重新初始化数据库同步
    sql
    -- 将辅助副本重新加入可用性组
ALTER AVAILABILITY GROUP [YourAGName] JOIN;
GO

-- 初始化数据库同步
ALTER DATABASE [YourDatabaseName] SET HADR AVAILABILITY GROUP = [YourAGName];
GO

数据库故障恢复 ​

当可用性组中的数据库发生故障时，需要恢复数据库并将其重新加入可用性组：

  1. 修复数据库：

    • 从备份恢复数据库
    • 修复数据库一致性错误
    • 重建数据库（如果需要）

  2. 将数据库重新加入可用性组：

    • 在主副本上恢复数据库
    • 将数据库重新加入可用性组
    • 重新初始化数据库同步
    sql
    -- 将数据库重新加入可用性组
ALTER DATABASE [YourDatabaseName] SET HADR AVAILABILITY GROUP = [YourAGName];
GO

故障处理最佳实践 ​

事前准备 ​

  1. 建立完善的监控体系：

    • 监控可用性组的状态和健康情况
    • 监控副本的同步状态
    • 监控数据库的同步状态
    • 配置告警，及时通知 DBA

  2. 制定详细的故障处理流程：

    • 明确故障检测、诊断和处理的步骤
    • 明确各角色的职责和权限
    • 制定故障切换的决策标准
    • 制定回滚计划

  3. 定期测试故障切换：

    • 定期执行故障切换测试，验证故障切换机制的有效性
    • 测试不同场景下的故障切换，如主副本故障、网络故障等
    • 记录测试结果，优化故障处理流程

  4. 备份和恢复策略：

    • 定期备份可用性组中的数据库
    • 测试备份的可恢复性
    • 制定详细的恢复计划

事中处理 ​

  1. 快速定位故障：

    • 使用监控工具快速定位故障点
    • 分析故障原因，确定故障类型
    • 评估故障对业务的影响

  2. 执行故障切换：

    • 根据故障类型选择合适的故障切换方式
    • 执行故障切换操作
    • 验证故障切换结果

  3. 通知相关人员：

    • 及时通知业务部门和管理层
    • 提供故障处理的进展情况
    • 预计恢复时间

事后总结 ​

  1. 故障分析：

    • 分析故障的根本原因
    • 评估故障处理的效果
    • 总结经验教训

  2. 优化改进：

    • 优化可用性组配置
    • 优化故障检测和监控机制
    • 优化故障处理流程

  3. 文档更新：

    • 更新故障处理文档
    • 记录故障处理的详细过程
    • 记录故障处理的经验教训

版本差异 ​

SQL Server 2012 ​

  • 引入 AlwaysOn Availability Groups 功能
  • 支持最多 4 个辅助副本
  • 支持自动故障切换

SQL Server 2014 ​

  • 改进了 AlwaysOn Availability Groups 的性能和可扩展性
  • 支持最多 8 个辅助副本
  • 引入了 AlwaysOn Availability Groups 的只读路由功能

SQL Server 2016 ​

  • 引入了分布式可用性组
  • 支持最多 10 个辅助副本
  • 改进了故障检测和故障切换机制

SQL Server 2017+ ​

  • 支持 Linux 环境下的 AlwaysOn Availability Groups
  • 增强了与 Azure SQL Database 的集成
  • 改进了可用性组的性能和可靠性

SQL Server 2022 ​

  • 进一步优化了 AlwaysOn Availability Groups 的性能
  • 引入了加速数据库恢复 (ADR) 功能，提高故障恢复速度
  • 增强了可用性组的安全性

常见问题 (FAQ) ​

Q: Always On Availability Groups 支持哪些类型的故障切换？ ​

A: Always On Availability Groups 支持两种类型的故障切换：

  1. 自动故障切换：当主副本发生故障时，自动将辅助副本提升为主副本
  2. 手动故障切换：包括计划内故障切换（同步故障切换，不丢失数据）和强制故障切换（异步故障切换，可能丢失数据）

Q: 如何提高 Always On Availability Groups 的故障检测敏感度？ ​

A: 可以通过以下方式提高故障检测敏感度：

  1. 调整 HEARTBEAT_TIMEOUT 参数，减少心跳超时时间
  2. 调整 FAILURE_CONDITION_LEVEL 参数，提高故障检测的敏感度
  3. 优化网络连接，减少网络延迟

Q: 如何处理 Always On Availability Groups 故障切换失败的情况？ ​

A: 处理故障切换失败的步骤包括：

  1. 查看故障日志，分析故障切换失败的原因
  2. 检查副本的状态和健康情况
  3. 检查网络连接
  4. 检查 SQL Server 服务状态
  5. 尝试手动故障切换
  6. 如果手动故障切换也失败，考虑重建可用性组

Q: Always On Availability Groups 故障切换会影响客户端连接吗？ ​

A: 故障切换期间，客户端连接会暂时中断，但如果使用可用性组侦听器连接数据库，客户端会自动重新连接到新的主副本。为了减少故障切换对客户端的影响，建议：

  1. 使用可用性组侦听器连接数据库
  2. 配置合适的连接超时时间和重试机制
  3. 优化应用程序代码，处理连接中断情况

Q: 如何监控 Always On Availability Groups 的故障切换历史？ ​

A: 可以通过以下方式监控故障切换历史：

  1. 查看 SQL Server 错误日志
  2. 查看 Windows 事件日志
  3. 使用扩展事件捕获故障切换事件
  4. 使用动态管理视图查询故障切换历史
  5. 使用复制监视器查看故障切换历史

实际生产运维场景 ​

主副本服务器硬件故障 ​

场景：生产环境中，Always On Availability Groups 的主副本服务器发生硬件故障，无法正常运行。

处理步骤：

  1. 确认主副本服务器硬件故障，无法恢复
  2. 检查辅助副本的同步状态，确认是否有同步提交模式的辅助副本处于同步状态
  3. 执行强制故障切换，将同步状态良好的辅助副本提升为主副本
  4. 验证新主副本的状态和数据库的可用性
  5. 通知业务部门，恢复业务服务
  6. 修复或更换故障的主副本服务器
  7. 将修复后的服务器重新加入可用性组，作为辅助副本

网络故障导致副本断开连接 ​

场景：生产环境中，由于网络故障，Always On Availability Groups 的主副本和辅助副本之间的连接断开。

处理步骤：

  1. 确认网络故障，联系网络管理员修复网络问题
  2. 监控副本的状态，等待网络恢复
  3. 网络恢复后，检查副本的同步状态
  4. 如果副本自动重新连接并同步，验证数据一致性
  5. 如果副本无法自动重新连接，手动将副本重新加入可用性组
  6. 分析网络故障原因，采取措施防止类似故障再次发生

数据库事务日志损坏 ​

场景：生产环境中，Always On Availability Groups 的主副本数据库事务日志损坏，导致数据库无法正常运行。

处理步骤：

  1. 确认数据库事务日志损坏，无法修复
  2. 执行计划内故障切换，将辅助副本提升为主副本
  3. 在新主副本上验证数据库的可用性
  4. 通知业务部门，恢复业务服务
  5. 在原主副本上重建数据库
  6. 将重建后的数据库重新加入可用性组
  7. 分析事务日志损坏的原因，采取措施防止类似故障再次发生

总结 ​

Always On Availability Groups 是 SQL Server 提供的强大高可用解决方案，但在实际生产环境中，仍然可能遇到各种故障。DBA 需要建立完善的监控体系，制定详细的故障处理流程，定期测试故障切换机制，以便在故障发生时能够快速检测、诊断和处理故障，确保业务连续性。同时，DBA 还需要不断总结经验教训，优化可用性组配置和故障处理流程，提高系统的可靠性和可用性。