印刻数据库

外观

SQLServer 故障恢复与高可用性开发 ​

故障概述 ​

故障定义 ​

SQL Server 故障是指数据库系统在运行过程中出现的各种异常情况，导致系统无法正常提供服务或数据完整性受到威胁。故障恢复开发的核心目标是确保在发生故障时，系统能够快速、可靠地恢复服务，最小化业务中断时间。

故障类型 ​

生产环境常见故障类型：

  • 硬件故障：服务器硬件故障、存储设备故障、网络设备故障
  • 软件故障：SQL Server 服务崩溃、操作系统故障、应用程序错误
  • 数据故障：数据损坏、日志文件损坏、索引损坏
  • 网络故障：网络连接中断、网络延迟过高、DNS 故障
  • 人为故障：误操作、配置错误、安全攻击

故障影响 ​

故障对业务的影响程度取决于多个因素：

  • 故障持续时间：影响业务连续性和用户体验
  • 数据丢失程度：影响数据完整性和业务可靠性
  • 影响范围：单数据库、单实例或整个系统
  • 恢复时间：RTO（恢复时间目标）和 RPO（恢复点目标）的达成情况

故障检测 ​

故障检测机制 ​

生产环境实践：

  • 心跳检测：通过定期发送心跳信号检测服务器可用性
  • 服务状态监控：监控 SQL Server 服务、代理服务和其他关键服务
  • 连接性检测：定期测试数据库连接，验证服务可用性
  • 性能指标监控：监控 CPU、内存、磁盘 I/O 等性能指标，预测潜在故障
  • 数据一致性检测：定期检查数据库完整性，检测数据损坏

监控工具 ​

生产环境常用监控工具：

  • SQL Server Management Studio (SSMS)：内置的活动监视器和报表
  • SQL Server Profiler：捕获和分析 SQL Server 事件
  • Extended Events：轻量级事件跟踪系统，适合生产环境
  • Performance Monitor：监控系统和 SQL Server 性能计数器
  • SQL Server Agent：配置警报和作业监控
  • 第三方工具：Redgate SQL Monitor、SolarWinds Database Performance Monitor、Idera SQL Diagnostic Manager

告警配置 ​

生产环境告警最佳实践：

  • 配置多级告警机制，区分严重程度（信息、警告、错误、严重）
  • 设置合理的告警阈值，避免误报和漏报
  • 配置多种告警渠道：邮件、短信、企业微信、Slack 等
  • 建立告警响应流程，明确责任人和处理步骤
  • 定期测试告警配置，确保告警能够及时送达

示例告警配置：

sql
-- 配置 SQL Server Agent 告警
USE [msdb]
GO
EXEC msdb.dbo.sp_add_alert @name=N'SQL Server 服务停止', 
    @message_id=0, 
    @severity=0, 
    @enabled=1, 
    @delay_between_responses=300, 
    @include_event_description_in=1,
    @category_name=N'[Uncategorized]', 
    @performance_condition=N'SQLServer:General Statistics|User Connections|_|_|_<|1', 
    @job_id=N'00000000-0000-0000-0000-000000000000'
GO

故障诊断 ​

生产环境故障诊断流程：

  1. 收集故障信息：错误日志、事件查看器、性能计数器、扩展事件
  2. 分析故障原因：确定故障类型和根本原因
  3. 评估影响范围：确定受影响的数据库、用户和业务流程
  4. 制定恢复方案：根据故障类型和影响范围选择合适的恢复方法
  5. 执行恢复操作：按照恢复方案执行恢复操作
  6. 验证恢复结果：确认系统恢复正常，数据完整

故障转移 ​

故障转移定义 ​

故障转移是指在主数据库系统发生故障时，将业务流量自动或手动切换到备用数据库系统的过程。故障转移的目标是最小化业务中断时间，确保数据一致性。

故障转移类型 ​

生产环境常见故障转移类型：

  • 自动故障转移：无需人工干预，系统自动检测故障并完成切换
  • 手动故障转移：需要人工干预，由管理员根据故障情况决定是否执行切换
  • 计划内故障转移：预先计划的维护操作，如硬件升级、软件更新
  • 计划外故障转移：意外故障导致的紧急切换

故障转移流程 ​

典型故障转移流程：

  1. 故障检测：监控系统检测到主节点故障
  2. 故障确认：进行二次确认，避免误判
  3. 切换准备：准备备用节点，确保其可用
  4. 流量切换：将业务流量切换到备用节点
  5. 服务恢复：在备用节点上恢复服务
  6. 验证测试：验证服务是否正常运行

故障转移验证 ​

故障转移后验证步骤：

  1. 服务可用性验证：确认数据库服务正常运行
  2. 数据一致性验证：检查数据是否完整一致
  3. 应用程序验证：测试应用程序能否正常连接和使用
  4. 性能验证：确认系统性能符合要求
  5. 业务功能验证：验证关键业务功能正常运行

Always On 故障转移 ​

Always On 故障转移机制 ​

Always On 可用性组是 SQL Server 2012 引入的高可用性解决方案，它将多个数据库作为一个组进行故障转移管理。Always On 支持自动故障转移、手动故障转移和计划内故障转移。

手动故障转移 ​

生产环境实践：

sql
-- 手动故障转移 Always On 可用性组
ALTER AVAILABILITY GROUP [AG_ECommerce] FAILOVER;

自动故障转移 ​

自动故障转移配置：

  • 至少需要两个故障转移伙伴
  • 配置自动故障转移模式
  • 设置合适的故障检测阈值
  • 配置只读路由，实现读写分离

故障转移后处理 ​

Always On 故障转移后处理：

  1. 确认可用性组状态正常
  2. 更新应用程序连接字符串（如果需要）
  3. 检查和修复任何孤立用户
  4. 验证代理作业和维护计划
  5. 监控新主节点的性能

FCI 故障转移 ​

FCI 故障转移机制 ​

故障转移集群实例（FCI）是基于 Windows Server 故障转移集群（WSFC）的高可用性解决方案，它将 SQL Server 实例安装在集群节点上，共享存储。当一个节点故障时，另一个节点接管服务。

手动故障转移 ​

生产环境实践：

  • 使用故障转移集群管理器进行手动故障转移
  • 使用 PowerShell 命令进行故障转移：
    powershell
    Move-ClusterGroup -Name "SQL Server (INSTANCE1)" -Node "Node2"

自动故障转移 ​

FCI 自动故障转移配置：

  • 配置集群节点的优先级
  • 设置故障检测阈值
  • 配置资源依赖关系
  • 测试集群故障转移

故障转移后处理 ​

FCI 故障转移后处理：

  1. 确认集群资源状态正常
  2. 验证数据库文件访问权限
  3. 检查和修复任何磁盘问题
  4. 验证 SQL Server 服务和代理服务
  5. 监控新节点的性能

日志传送故障转移 ​

日志传送故障转移机制 ​

日志传送是 SQL Server 传统的高可用性解决方案，它通过定期备份主数据库日志，复制到备用服务器并还原，实现数据同步。日志传送只支持手动故障转移。

手动故障转移 ​

日志传送故障转移步骤：

  1. 在主服务器上执行最后的日志备份
  2. 将最后的日志备份复制到备用服务器
  3. 在备用服务器上还原最后的日志备份（WITH RECOVERY）
  4. 更新应用程序连接字符串，指向备用服务器
  5. 验证数据库服务正常运行

故障转移后处理 ​

日志传送故障转移后处理：

  1. 确认数据库处于可用状态
  2. 更新日志传送配置，将新的主服务器配置为源
  3. 重新配置备份和还原作业
  4. 验证数据一致性
  5. 监控新主服务器的性能

数据库镜像故障转移 ​

数据库镜像故障转移机制 ​

数据库镜像是 SQL Server 2005 引入的高可用性解决方案，它将数据库事务实时复制到备用服务器。数据库镜像支持自动故障转移、手动故障转移和强制故障转移。

注意：数据库镜像在 SQL Server 2016 中已被弃用，推荐使用 Always On 可用性组替代。

手动故障转移 ​

数据库镜像手动故障转移：

sql
-- 在主服务器上执行
ALTER DATABASE [ECommerce] SET PARTNER FAILOVER;

自动故障转移 ​

数据库镜像自动故障转移配置：

  • 配置高安全模式
  • 添加见证服务器
  • 配置镜像端点
  • 设置合适的超时值

故障转移后处理 ​

数据库镜像故障转移后处理：

  1. 确认镜像状态正常
  2. 更新应用程序连接字符串（如果需要）
  3. 验证数据库完整性
  4. 监控新主服务器的性能

故障恢复最佳实践 ​

故障恢复计划 ​

生产环境故障恢复计划：

  • 明确 RTO（恢复时间目标）和 RPO（恢复点目标）
  • 制定详细的故障恢复流程，包括责任人和联系方式
  • 配置合适的高可用性解决方案，根据业务需求选择 Always On、FCI 或其他方案
  • 定期更新故障恢复计划，确保与系统配置一致

故障恢复演练 ​

生产环境演练最佳实践：

  • 定期进行故障恢复演练，至少每季度一次
  • 演练不同类型的故障场景
  • 记录演练过程和结果，分析存在的问题
  • 优化故障恢复计划，改进恢复流程
  • 培训相关人员，确保他们熟悉恢复流程

故障恢复测试 ​

故障恢复测试方法：

  • 模拟故障测试：模拟不同类型的故障，测试恢复流程
  • 灾难恢复测试：在隔离环境中测试完整的灾难恢复流程
  • 性能测试：测试恢复后的系统性能，确保符合要求
  • 压力测试：测试恢复后系统的承载能力

故障恢复文档 ​

生产环境文档要求：

  • 详细的故障恢复流程文档
  • 系统架构图和拓扑图
  • 关键配置信息：IP 地址、端口号、账号密码等
  • 联系人列表：IT 运维、数据库管理员、应用开发人员
  • 历史故障记录和解决方案

故障恢复监控与报告 ​

故障恢复监控 ​

生产环境监控重点：

  • 监控故障恢复过程，确保按计划执行
  • 监控恢复后的系统性能，确认是否正常
  • 监控数据一致性，确保数据完整
  • 监控业务功能，确认关键业务正常运行

故障恢复报告 ​

故障恢复报告内容：

  • 故障基本信息：时间、类型、影响范围
  • 恢复过程：采取的措施、执行时间、参与人员
  • 恢复结果：RTO 和 RPO 达成情况、系统状态
  • 问题和改进：恢复过程中遇到的问题、改进建议
  • 经验教训：总结经验，避免类似问题再次发生

故障恢复分析 ​

故障恢复分析方法：

  • 进行根本原因分析，确定故障发生的根本原因
  • 评估恢复流程的有效性，找出改进空间
  • 分析 RTO 和 RPO 的达成情况，确定是否需要调整
  • 制定预防措施，避免类似故障再次发生

版本差异 ​

SQL Server 2008/2008 R2 ​

  • 支持数据库镜像、日志传送和 FCI
  • 不支持 Always On 可用性组
  • 数据库镜像支持自动故障转移（需要见证服务器）
  • FCI 基于 Windows Server 故障转移集群

SQL Server 2012 ​

  • 引入 Always On 可用性组
  • 增强了 FCI 支持
  • 数据库镜像仍然可用，但已开始推荐使用 Always On
  • 支持 Windows Server 2008 R2 和 Windows Server 2012

SQL Server 2014 ​

  • 增强了 Always On 可用性组，支持更多数据库
  • 引入了 Always On 可读辅助副本的自动故障转移
  • 支持 Windows Server 2012 和 Windows Server 2012 R2
  • 数据库镜像仍然可用

SQL Server 2016 ​

  • 增强了 Always On 可用性组，支持分布式可用性组
  • 数据库镜像被弃用，推荐使用 Always On
  • 增强了 FCI 支持，支持 Azure 虚拟机
  • 支持 Windows Server 2012 R2 和 Windows Server 2016

SQL Server 2017 ​

  • Always On 可用性组支持 Linux
  • 增强了分布式可用性组
  • 支持容器化部署
  • 支持 Windows Server 2016 和 Windows Server 2019

SQL Server 2019 ​

  • 增强了 Always On 可用性组，支持更多辅助副本
  • 引入了大数据集群
  • 支持 Windows Server 2019 和 Linux
  • 增强了自动故障转移逻辑

SQL Server 2022 ​

  • 增强了 Always On 可用性组，支持 Azure Synapse Link
  • 引入了 Ledger 功能，增强数据安全性
  • 支持 Windows Server 2022 和 Linux
  • 增强了故障检测和恢复机制

FAQ ​

如何选择合适的高可用性解决方案？ ​

选择高可用性解决方案需要考虑多个因素：

  • 业务需求：RTO 和 RPO 要求
  • 系统规模：数据库大小、用户数量、并发量
  • 预算限制：硬件、软件和维护成本
  • 技术复杂度：部署和维护难度
  • 团队技能：DBA 团队的技术水平

如何检测 SQL Server 故障？ ​

检测 SQL Server 故障的方法包括：

  • 使用心跳检测机制，定期发送心跳信号
  • 监控 SQL Server 服务状态和连接性
  • 监控性能指标，如 CPU、内存、磁盘 I/O
  • 使用 Extended Events 或 SQL Server Profiler 捕获异常事件
  • 定期检查数据库完整性，检测数据损坏

如何配置自动故障转移？ ​

配置自动故障转移的步骤：

  • 选择支持自动故障转移的高可用性解决方案，如 Always On 可用性组（同步提交模式）、数据库镜像（高安全模式带见证服务器）或 FCI
  • 配置合适的故障检测阈值和超时值
  • 添加足够的故障转移伙伴
  • 测试自动故障转移，确保其正常工作
  • 配置告警机制，及时通知故障转移事件

故障转移需要多长时间？ ​

故障转移时间取决于多个因素：

  • 高可用性解决方案：Always On 可用性组通常在秒级完成，FCI 在分钟级，日志传送需要手动干预
  • 系统规模：数据库大小、事务量
  • 网络状况：网络延迟和带宽
  • 故障类型：硬件故障、软件故障或网络故障

故障转移后需要做什么？ ​

故障转移后的关键操作：

  • 确认系统状态正常，所有服务运行正常
  • 验证数据一致性，确保没有数据丢失
  • 更新应用程序连接字符串（如果需要）
  • 检查和修复任何孤立用户
  • 验证代理作业和维护计划是否正常运行
  • 监控新主节点的性能，确保其符合要求

如何测试故障恢复计划？ ​

测试故障恢复计划的方法：

  • 制定详细的测试计划，包括测试场景、步骤和预期结果
  • 在隔离环境中进行测试，避免影响生产系统
  • 模拟不同类型的故障，测试恢复流程
  • 记录测试过程和结果，分析存在的问题
  • 优化故障恢复计划，改进恢复流程
  • 定期进行测试，确保计划的有效性

Always On 可用性组和 FCI 有什么区别？ ​

Always On 可用性组和 FCI 的主要区别：

  • 架构：Always On 基于数据库级别的复制，FCI 基于实例级别的共享存储
  • 故障转移：Always On 可以实现数据库级别的故障转移，FCI 实现实例级别的故障转移
  • 存储：Always On 每个副本都有独立的存储，FCI 共享存储
  • 扩展性：Always On 支持更多的辅助副本，FCI 受限于集群节点数量
  • 成本：Always On 需要企业版 SQL Server，FCI 可以使用标准版

如何处理故障恢复过程中的数据不一致问题？ ​

处理数据不一致问题的方法：

  • 定期进行数据库完整性检查，提前发现数据损坏
  • 配置合适的备份策略，确保有可用的备份
  • 使用页修复或数据库修复命令修复损坏的数据
  • 如果数据损坏严重，考虑从备份恢复
  • 分析数据损坏的根本原因，采取预防措施

如何优化故障恢复时间？ ​

优化故障恢复时间的方法：

  • 选择合适的高可用性解决方案，如 Always On 可用性组
  • 配置自动故障转移，减少人工干预
  • 优化恢复流程，简化恢复步骤
  • 定期进行故障恢复演练，提高恢复效率
  • 确保备份策略合理，备份恢复速度快
  • 优化硬件配置，提高恢复性能

如何确保故障恢复过程中的数据安全？ ​

确保数据安全的方法：

  • 配置合适的权限，限制恢复操作的执行权限
  • 记录恢复过程，便于审计和追踪
  • 验证恢复后的数据完整性，确保数据没有被篡改
  • 加密敏感数据，保护数据安全
  • 建立数据备份的安全存储机制，防止备份丢失或被盗

如何监控故障转移事件？ ​

监控故障转移事件的方法：

  • 使用 SQL Server 错误日志，查看故障转移相关日志
  • 配置 SQL Server Agent 警报，及时通知故障转移事件
  • 使用 Extended Events 捕获故障转移事件
  • 使用第三方监控工具，如 Redgate SQL Monitor 或 SolarWinds Database Performance Monitor
  • 配置 Windows 事件日志监控，查看集群相关事件

如何制定合理的 RTO 和 RPO 目标？ ​

制定 RTO 和 RPO 目标的方法：

  • 评估业务影响，确定可接受的业务中断时间
  • 考虑数据重要性，确定可接受的数据丢失程度
  • 分析系统恢复能力，确定实际可达到的恢复时间
  • 平衡成本和恢复能力，选择合适的高可用性解决方案
  • 定期评估和调整 RTO 和 RPO 目标，适应业务变化