印刻数据库

外观

SQLServer 高可用问题 ​

高可用问题概述 ​

SQL Server 高可用方案旨在确保数据库服务的连续性和数据的完整性。然而，在实际生产环境中，各种高可用方案都可能遇到不同类型的问题。了解这些问题的症状、诊断方法和解决方案对于维持数据库服务的稳定性至关重要。

高可用方案的常见类型 ​

SQL Server 提供多种高可用解决方案，每种方案都有其适用场景和潜在问题：

  • Always On 可用性组：SQL Server 2012 及以上版本提供的高级高可用功能，支持多个数据库的故障转移
  • 故障转移集群实例 (FCI)：基于 Windows Server 故障转移集群，提供实例级别的高可用
  • 日志传送：通过定期传送事务日志实现数据库复制和故障转移
  • 数据库镜像：SQL Server 2005-2016 支持的数据库级别的高可用方案，已被 Always On 取代
  • 复制：用于数据分发和同步，支持多种拓扑结构

高可用问题的常见症状 ​

  • 应用程序连接失败或超时
  • 数据同步延迟或中断
  • 故障转移无法自动触发或失败
  • 高可用组件状态异常
  • 性能下降或资源占用过高
  • 监控告警频繁触发

高可用问题的影响 ​

  • 业务中断导致收入损失
  • 数据丢失或不一致
  • 客户信任度下降
  • 运维成本增加
  • 合规风险

高可用问题的诊断步骤 ​

  1. 收集信息：记录问题发生时间、症状、错误日志和监控数据
  2. 检查组件状态：使用系统视图和工具检查高可用组件的当前状态
  3. 分析日志：查看 SQL Server 错误日志、Windows 事件日志和集群日志
  4. 验证配置：检查高可用方案的配置是否符合最佳实践
  5. 测试故障转移：在安全环境中测试故障转移过程
  6. 实施解决方案：根据诊断结果实施相应的解决方案
  7. 验证修复效果：确认问题已解决并监控系统状态

Always On 可用性组问题 ​

Always On 可用性组是 SQL Server 2012 及以上版本的核心高可用功能，用于保护多个数据库并支持自动故障转移。

Always On 可用性组概述 ​

Always On 可用性组由一个主副本和多个辅助副本组成，通过同步或异步方式复制数据。主副本处理所有读写请求，辅助副本可用于只读访问和故障转移。

常见问题类型 ​

  1. 同步超时或失败
  2. 自动故障转移无法触发
  3. 辅助副本状态异常
  4. 可用性组监听无法访问
  5. 只读路由配置问题
  6. 备份偏好设置问题

诊断 Always On 问题 ​

检查可用性组状态：

sql
SELECT ag.name AS AGName,
       ar.replica_server_name AS ReplicaName,
       ars.role_desc AS Role,
       ars.operational_state_desc AS OperationalState,
       ars.synchronization_health_desc AS SyncHealth,
       ars.last_connect_error_number AS LastErrorNumber,
       ars.last_connect_error_description AS LastErrorDescription,
       ars.last_connect_error_timestamp AS LastErrorTime
FROM sys.dm_hadr_availability_replica_states ars
JOIN sys.availability_replicas ar ON ars.replica_id = ar.replica_id
JOIN sys.availability_groups ag ON ars.group_id = ag.group_id;

检查数据库同步状态：

sql
SELECT ag.name AS AGName,
       ar.replica_server_name AS ReplicaName,
       db_name(drs.database_id) AS DatabaseName,
       drs.synchronization_state_desc AS SyncState,
       drs.synchronization_health_desc AS SyncHealth,
       drs.last_hardened_lsn AS LastHardenedLSN,
       drs.last_redone_lsn AS LastRedoneLSN,
       drs.redo_queue_size AS RedoQueueSize,
       drs.log_send_queue_size AS LogSendQueueSize
FROM sys.dm_hadr_database_replica_states drs
JOIN sys.availability_replicas ar ON drs.replica_id = ar.replica_id
JOIN sys.availability_groups ag ON drs.group_id = ag.group_id;

解决 Always On 问题 ​

1. 同步超时或失败

  • 检查网络连接和带宽
  • 调整 SESSION_TIMEOUT 设置：
    sql
    ALTER AVAILABILITY GROUP [AGName] MODIFY REPLICA ON N'ReplicaName' WITH (SESSION_TIMEOUT = 30);
  • 检查主副本和辅助副本的系统资源使用情况

2. 辅助副本状态异常

  • 检查 SQL Server 服务状态
  • 验证端点配置：
    sql
    SELECT name, state_desc, type_desc, port FROM sys.tcp_endpoints WHERE type_desc = 'DATABASE_MIRRORING';
  • 检查防火墙配置，确保端点端口可访问

3. 可用性组监听无法访问

  • 检查监听配置：
    sql
    SELECT name, port, ip_configuration_string_from_cluster FROM sys.availability_group_listeners;
  • 验证集群资源状态：
    powershell
    Get-ClusterResource | Where-Object {$_.ResourceType -eq "IP Address"} | Get-ClusterParameter
  • 检查 DNS 解析是否正常

版本差异 ​

  • SQL Server 2012：首次引入 Always On 可用性组，仅支持 2 个辅助副本
  • SQL Server 2014：支持最多 4 个辅助副本，引入 Always On 仪表盘
  • SQL Server 2016：支持最多 8 个辅助副本，增强了自动故障转移功能
  • SQL Server 2017+：支持 Linux 平台，增强了性能和安全性

故障转移集群实例 (FCI) 问题 ​

故障转移集群实例基于 Windows Server 故障转移集群，提供实例级别的高可用，适用于需要实例级故障转移的场景。

FCI 概述 ​

FCI 将 SQL Server 实例安装在 Windows Server 故障转移集群上，共享存储或使用 Storage Spaces Direct。当节点故障时，实例会自动转移到其他节点。

常见问题类型 ​

  1. 集群节点状态异常
  2. 资源组无法上线
  3. 共享存储访问问题
  4. 故障转移失败
  5. 集群网络问题

诊断 FCI 问题 ​

检查集群状态：

powershell
Get-ClusterNode | Select-Object Name, State
Get-ClusterResource | Select-Object Name, State, OwnerNode

检查 SQL Server 集群日志：

sql
EXEC xp_readerrorlog 0, 1, N'cluster';

检查资源依赖关系：

powershell
Get-ClusterResourceDependency 'SQL Server'

解决 FCI 问题 ​

1. 资源组无法上线

  • 检查资源依赖关系是否正确
  • 验证共享存储是否可访问
  • 检查 SQL Server 服务账户权限
  • 查看集群事件日志获取详细错误信息

2. 故障转移失败

  • 检查节点间通信是否正常：
    powershell
    Test-Cluster
  • 调整故障转移策略：
    powershell
    Set-ClusterGroup -Name 'SQL Server' -FailoverThreshold 3 -FailoverPeriod 6
  • 验证存储访问权限

3. 集群网络问题

  • 检查集群网络配置：
    powershell
    Get-ClusterNetwork | Select-Object Name, Address, State, Role
  • 验证心跳网络连通性
  • 检查防火墙配置，确保集群端口可访问

版本差异 ​

  • SQL Server 2012：支持 Windows Server 2008 R2 及以上版本
  • SQL Server 2016：支持 Storage Spaces Direct 和 Azure 虚拟机
  • SQL Server 2019：增强了对 Linux 集群的支持

日志传送问题 ​

日志传送是一种基于事务日志的高可用解决方案，通过定期备份、复制和还原事务日志实现数据库的异步复制。

日志传送概述 ​

日志传送由三个主要作业组成：备份作业（主服务器）、复制作业（辅助服务器）和还原作业（辅助服务器）。

常见问题类型 ​

  1. 备份作业失败
  2. 复制作业无法访问备份文件
  3. 还原作业失败
  4. 辅助数据库与主数据库差距过大
  5. 监控警报频繁触发

诊断日志传送问题 ​

检查日志传送状态：

sql
EXEC sp_help_log_shipping_monitor;

检查详细日志传送配置：

sql
SELECT * FROM msdb.dbo.log_shipping_primary_databases;
SELECT * FROM msdb.dbo.log_shipping_secondary_databases;

解决日志传送问题 ​

1. 备份作业失败

  • 检查备份目录权限
  • 验证磁盘空间是否充足
  • 检查日志文件状态：
    sql
    DBCC CHECKDB (DatabaseName) WITH NO_INFOMSGS;

2. 辅助数据库与主数据库差距过大

  • 调整备份、复制和还原作业的频率
  • 检查网络带宽和延迟
  • 考虑使用差异备份进行初始同步

3. 还原作业失败

  • 检查辅助数据库的恢复模式
  • 验证还原目录权限
  • 检查事务日志链是否完整：
    sql
    SELECT name, recovery_model_desc FROM sys.databases;

版本差异 ​

  • SQL Server 2005+：支持日志传送功能
  • SQL Server 2012+：可与 Always On 可用性组结合使用
  • SQL Server 2016+：增强了日志传送的监控和管理功能

数据库镜像问题 ​

数据库镜像是 SQL Server 2005-2016 支持的数据库级别的高可用方案，已在 SQL Server 2016 及以上版本中被 Always On 可用性组取代。

数据库镜像概述 ​

数据库镜像将单个数据库的事务日志发送到另一个服务器上的镜像数据库，支持同步和异步模式。

常见问题类型 ​

  1. 镜像会话断开
  2. 同步超时
  3. 故障转移失败
  4. 见证服务器问题
  5. 性能下降

诊断数据库镜像问题 ​

检查镜像状态：

sql
SELECT db.name AS DatabaseName,
       dm.mirroring_state_desc AS MirrorState,
       dm.mirroring_role_desc AS Role,
       dm.mirroring_partner_name AS PartnerName,
       dm.mirroring_witness_name AS WitnessName,
       dm.mirroring_witness_state_desc AS WitnessState,
       dm.mirroring_connection_timeout AS ConnectionTimeout,
       dm.mirroring_redo_queue AS RedoQueue,
       dm.mirroring_log_send_queue AS LogSendQueue
FROM sys.database_mirroring dm
JOIN sys.databases db ON dm.database_id = db.database_id
WHERE dm.mirroring_guid IS NOT NULL;

解决数据库镜像问题 ​

1. 镜像会话断开

  • 检查端点配置：
    sql
    SELECT name, state_desc, type_desc, port FROM sys.tcp_endpoints WHERE type_desc = 'DATABASE_MIRRORING';
  • 验证网络连接和防火墙配置
  • 重启镜像会话：
    sql
    ALTER DATABASE DatabaseName SET PARTNER RESUME;

2. 同步超时

  • 调整超时设置：
    sql
    ALTER DATABASE DatabaseName SET PARTNER TIMEOUT 30;
  • 检查网络带宽和延迟
  • 优化数据库性能，减少事务日志生成

版本差异 ​

  • SQL Server 2005：首次引入数据库镜像
  • SQL Server 2008：增强了镜像性能和安全性
  • SQL Server 2016：将数据库镜像标记为已弃用，推荐使用 Always On 可用性组

复制问题 ​

复制是 SQL Server 的数据分发技术，用于在多个服务器之间同步数据，支持多种拓扑结构。

复制概述 ​

复制由发布服务器、分发服务器和订阅服务器组成，支持快照复制、事务复制和合并复制三种类型。

常见问题类型 ​

  1. 复制代理失败
  2. 数据同步延迟
  3. 冲突检测和解决
  4. 复制监控问题
  5. 架构更改传播问题

诊断复制问题 ​

检查复制代理状态：

sql
EXEC sp_help_job @job_type = 'REPL';

检查复制监视器数据：

sql
SELECT * FROM distribution.dbo.MSdistribution_status;
SELECT * FROM distribution.dbo.MSlogreader_history WHERE runstatus != 2 ORDER BY time DESC;

解决复制问题 ​

1. 复制代理失败

  • 检查代理作业历史记录获取详细错误信息
  • 验证代理账户权限
  • 检查网络连接和共享访问权限

2. 数据同步延迟

  • 调整代理配置，增加并行度：
    sql
    EXEC sp_changepublication @publication = 'PublicationName', @property = 'max_concurrent_merge', @value = '10';
  • 优化复制拓扑，减少订阅服务器数量
  • 增加分发服务器资源

3. 架构更改传播问题

  • 确保使用 sp_repladdcolumn 或 sp_repldropcolumn 进行架构更改
  • 重新初始化订阅（必要时）

版本差异 ​

  • SQL Server 2005+：支持基本复制功能
  • SQL Server 2012+：增强了复制的监控和管理功能
  • SQL Server 2016+：支持 Always On 可用性组中的复制发布服务器

故障转移问题 ​

故障转移是高可用方案的核心功能，确保在主服务器故障时能够自动或手动切换到备用服务器。

故障转移概述 ​

故障转移分为自动故障转移和手动故障转移两种类型，每种类型都有其特定的触发条件和执行流程。

手动故障转移问题 ​

  • 手动故障转移超时
  • 故障转移后应用程序连接失败
  • 数据一致性问题

自动故障转移问题 ​

  • 自动故障转移无法触发
  • 不必要的故障转移（误触发）
  • 故障转移后服务无法启动

故障转移后问题 ​

  • 应用程序连接字符串需要更新
  • 性能下降
  • 辅助副本无法重新加入高可用组
  • 监控配置需要调整

示例代码与解决方案 ​

手动故障转移 Always On 可用性组：

sql
-- 在主副本上执行（同步模式）
ALTER AVAILABILITY GROUP [AGName] FAILOVER;

-- 在辅助副本上执行（强制故障转移，可能导致数据丢失）
ALTER AVAILABILITY GROUP [AGName] FORCE_FAILOVER_ALLOW_DATA_LOSS;

故障转移后验证数据一致性：

sql
-- 检查数据库状态
SELECT name, state_desc, recovery_model_desc FROM sys.databases;

-- 运行一致性检查
DBCC CHECKDB (DatabaseName) WITH NO_INFOMSGS, PHYSICAL_ONLY;

高可用监控问题 ​

有效的监控是确保高可用方案正常运行的关键，能够及时发现和解决潜在问题。

监控概述 ​

高可用监控应覆盖以下方面：

  • 组件状态和健康状况
  • 数据同步延迟
  • 资源使用情况
  • 故障转移事件
  • 性能指标

监控工具选择 ​

  • SQL Server Management Studio (SSMS)：内置的高可用监控功能
  • SQL Server 监控视图：动态管理视图和系统表
  • Windows 性能监视器：监控系统资源使用情况
  • SQL Server Agent 警报：基于事件的告警机制
  • 第三方监控工具：如 SolarWinds, Redgate SQL Monitor 等
  • Azure Monitor：用于 Azure SQL 数据库和 Azure VM 上的 SQL Server

常见监控问题 ​

  • 监控指标选择不当，导致告警过多或过少
  • 监控频率不合理，无法及时发现问题
  • 告警通知机制不健全，导致问题响应延迟
  • 监控数据存储和分析困难

解决监控问题 ​

  1. 优化监控指标：选择关键指标，避免监控过多非关键指标
  2. 调整监控频率：根据指标的重要性和变化频率调整监控间隔
  3. 完善告警机制：配置多级告警，确保问题能够及时通知到相关人员
  4. 建立监控数据仓库：长期存储监控数据，用于趋势分析和容量规划
  5. 自动化响应：对常见问题实现自动化响应和修复

监控最佳实践 ​

  • 建立监控基线，便于识别异常情况
  • 实施端到端监控，覆盖从应用程序到数据库的整个链路
  • 定期审查监控配置和告警规则
  • 培训运维人员，提高监控数据的分析能力
  • 结合日志分析和监控数据，全面了解系统状态

高可用性能问题 ​

高可用方案在提供服务连续性的同时，也可能对系统性能产生影响。了解和优化这些影响对于维持系统的整体性能至关重要。

高可用对性能的影响 ​

  • 同步开销：同步复制会增加主服务器的事务提交延迟
  • 资源消耗：辅助服务器需要额外的 CPU、内存和存储资源
  • 网络带宽：数据同步需要消耗网络带宽
  • 备份影响：在辅助服务器上执行备份可能影响辅助服务器的性能

性能瓶颈识别 ​

  • 使用性能监视器监控关键指标：

    • 事务提交时间
    • 日志发送队列大小
    • 重做队列大小
    • 网络吞吐量
    • CPU 和内存使用率

  • 使用 SQL Server 动态管理视图：

    sql
    SELECT * FROM sys.dm_os_performance_counters WHERE object_name LIKE '%Availability Replica%';
SELECT * FROM sys.dm_os_performance_counters WHERE object_name LIKE '%Database Mirroring%';

性能优化方法 ​

  1. 选择合适的同步模式：对关键数据库使用同步模式，对非关键数据库使用异步模式
  2. 优化网络配置：确保高可用组件之间的网络带宽充足，延迟低
  3. 调整辅助服务器配置：为辅助服务器分配足够的资源，特别是用于重做操作的资源
  4. 优化备份策略：在低峰期执行备份，或使用压缩备份减少网络传输量
  5. 使用 read_scale_out 配置：将只读工作负载分流到辅助副本

示例代码与解决方案 ​

调整 Always On 可用性组的同步模式：

sql
-- 将辅助副本改为异步提交模式
ALTER AVAILABILITY GROUP [AGName] MODIFY REPLICA ON N'ReplicaName' WITH (AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT);

配置只读路由：

sql
-- 在主副本上配置只读路由 URL
ALTER AVAILABILITY GROUP [AGName] MODIFY REPLICA ON N'ReplicaName' WITH (SECONDARY_ROLE(READ_ONLY_ROUTING_URL = N'TCP://ReplicaServer:1433'));

-- 配置只读路由列表
ALTER AVAILABILITY GROUP [AGName] ADD READ_ONLY_ROUTING_LIST = (N'ReplicaName1', N'ReplicaName2');

高可用灾备演练问题 ​

定期进行灾备演练是确保高可用方案在实际故障发生时能够正常工作的关键。

演练概述 ​

灾备演练是模拟实际故障场景，测试高可用方案的故障转移、数据恢复和业务连续性能力的过程。

演练计划制定 ​

  1. 确定演练目标和范围：明确演练的目的、测试的高可用方案和涉及的系统
  2. 制定演练步骤：详细规划演练的执行流程、角色分工和时间安排
  3. 准备测试环境：确保测试环境与生产环境一致，或能够模拟生产环境
  4. 制定回滚计划：确保在演练过程中出现问题时能够快速回滚到原始状态
  5. 通知相关人员：提前通知业务部门、运维团队和管理层

演练执行问题 ​

  • 演练步骤不明确，导致执行混乱
  • 测试环境与生产环境差异较大，演练结果不具有参考价值
  • 演练过程中出现意外问题，无法按照计划执行
  • 参与人员准备不足，无法有效执行演练步骤

演练后问题 ​

  • 演练结果分析不深入，无法识别潜在问题
  • 演练发现的问题没有及时修复
  • 演练经验没有总结和分享
  • 演练计划没有根据实际情况进行更新

演练最佳实践 ​

  1. 定期进行演练：至少每季度进行一次完整的灾备演练
  2. 模拟真实故障场景：包括硬件故障、软件故障和网络故障
  3. 测试端到端流程：从故障发生到业务恢复的完整流程
  4. 记录演练过程和结果：详细记录演练中的每一步操作和结果
  5. 及时修复发现的问题：将演练发现的问题纳入问题跟踪系统，及时修复
  6. 总结和分享经验：组织演练总结会议，分享经验教训和最佳实践

FAQ ​

如何诊断 Always On 可用性组问题？ ​

  1. 使用 sys.dm_hadr_availability_replica_states 和 sys.dm_hadr_database_replica_states 动态管理视图检查组件状态
  2. 查看 SQL Server 错误日志和集群日志，寻找相关错误信息
  3. 使用 SSMS 的 Always On 仪表板进行可视化监控
  4. 检查网络连接、防火墙配置和端点状态
  5. 验证可用性组监听配置和 DNS 解析

如何解决故障转移失败问题？ ​

  1. 检查故障转移集群或可用性组的配置是否正确
  2. 验证节点间通信和存储访问权限
  3. 查看错误日志获取详细错误信息
  4. 测试手动故障转移，确认故障转移机制是否正常工作
  5. 根据错误信息实施相应的解决方案，如调整超时设置、修复网络问题等

如何优化高可用方案的性能？ ​

  1. 根据业务需求选择合适的同步模式
  2. 为辅助服务器分配足够的资源
  3. 优化网络配置，确保高可用组件之间的网络带宽充足
  4. 合理配置备份策略，减少对主服务器的影响
  5. 使用只读路由将只读工作负载分流到辅助副本
  6. 定期监控和调整高可用配置，根据性能数据进行优化

如何进行高可用灾备演练？ ​

  1. 制定详细的演练计划，包括演练目标、范围、步骤和回滚计划
  2. 准备与生产环境一致的测试环境
  3. 按照计划执行演练，记录每一步操作和结果
  4. 测试故障转移、数据恢复和业务连续性
  5. 分析演练结果，识别潜在问题并及时修复
  6. 总结演练经验，更新演练计划和高可用配置

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

  1. 评估业务需求，包括 RTO（恢复时间目标）和 RPO（恢复点目标）
  2. 考虑预算限制和资源可用性
  3. 分析系统架构和现有基础设施
  4. 评估不同高可用方案的优缺点：
    • Always On 可用性组：适合需要保护多个数据库的场景
    • 故障转移集群实例：适合需要实例级高可用的场景
    • 日志传送：适合需要低成本、异步复制的场景
    • 复制：适合需要数据分发和同步的场景
  5. 结合业务需求和技术评估，选择最适合的高可用方案

如何监控高可用方案的状态？ ​

  1. 使用 SQL Server 内置的监控工具，如 SSMS 的高可用仪表板
  2. 配置 SQL Server Agent 警报，监控关键事件
  3. 使用动态管理视图和系统表收集监控数据
  4. 结合 Windows 性能监视器监控系统资源使用情况
  5. 考虑使用第三方监控工具，提供更全面的监控和告警功能
  6. 建立监控数据仓库，用于长期趋势分析和容量规划

如何处理高可用方案中的数据一致性问题？ ​

  1. 选择合适的同步模式，确保关键数据的一致性
  2. 定期验证主数据库和辅助数据库的数据一致性：
    sql
    -- 使用 CHECKSUM 验证数据一致性
DBCC CHECKDB (DatabaseName) WITH CHECKSUM;
  3. 建立数据一致性检查机制，及时发现和修复数据不一致问题
  4. 确保故障转移过程中的数据完整性，避免数据丢失
  5. 实施严格的变更管理流程，减少人为错误导致的数据不一致

如何提高高可用方案的可维护性？ ​

  1. 建立详细的文档，包括高可用方案的设计、配置和操作流程
  2. 实施自动化部署和配置管理，减少手动操作错误
  3. 建立标准化的维护流程，包括定期检查、备份和测试
  4. 培训运维团队，提高高可用方案的管理和维护能力
  5. 定期审查和更新高可用配置，确保符合最佳实践
  6. 建立问题跟踪和知识管理系统，积累维护经验

如何迁移到新的高可用方案？ ​

  1. 评估现有高可用方案的优缺点，确定迁移目标
  2. 制定详细的迁移计划，包括测试、部署和回滚策略
  3. 在测试环境中验证新的高可用方案
  4. 选择合适的迁移时机，尽量减少对业务的影响
  5. 实施迁移，监控迁移过程中的系统状态
  6. 验证迁移结果，确保新的高可用方案正常工作
  7. 逐步淘汰旧的高可用方案，完成迁移过程

如何处理高可用方案中的安全问题？ ​

  1. 确保高可用组件之间的通信加密：
    sql
    -- 为 Always On 端点配置加密
ALTER ENDPOINT [Hadr_endpoint] FOR DATA_MIRRORING (ENCRYPTION = REQUIRED ALGORITHM AES_256);
  2. 实施严格的访问控制，限制对高可用组件的访问
  3. 定期更新和修补 SQL Server 和操作系统
  4. 监控高可用方案的安全事件，及时发现和处理安全威胁
  5. 实施审计机制，记录对高可用组件的操作
  6. 培训运维人员，提高安全意识和操作规范