4、变更前可靠性检查清单:备份验证、磁盘空间检查、连接数监控、慢查询审计、资源使用率评估

在数据库变更窗口正式开启之前,执行一套结构化的可靠性检查是防止变更引发生产故障的最后一道防线。本章将围绕五个核心检查域——备份验证、磁盘空间、连接数、慢查询审计与资源使用率,提供可落地的检查清单与操作标准。

核心原则:变更前检查不是形式化的“打勾”,而是基于阈值与历史基线的量化评估。任何一项检查未通过,都应触发变更中止或回退流程。

4.1 备份验证:确保可恢复性

备份的存在不等于备份可用。变更前必须完成以下三项验证:

  • 完整性校验:对最近一次全量备份执行 RESTORE VERIFYONLY(SQL Server)或 pg_verifybackup(PostgreSQL),确认备份文件未损坏。
  • 恢复演练记录:检查最近30天内是否执行过至少一次完整的恢复演练,并记录恢复时间(RTO)与数据丢失量(RPO)。
  • 日志链连续性:对于使用事务日志的数据库(如SQL Server、Oracle),确认日志备份链未中断,且日志文件可连续应用。
数据库类型 验证命令/工具 关键检查项
MySQL mysqlbackup --backup-dir=... validate 备份集元数据完整性
PostgreSQL pg_verifybackup /backup/dir WAL文件连续性
SQL Server RESTORE VERIFYONLY FROM DISK='...' 页校验、文件存在性
Oracle RMAN VALIDATE BACKUPSET ... 物理块一致性
常见陷阱:仅检查备份文件大小或修改时间,而不执行实际校验。生产环境中曾多次出现备份文件“看起来正常”但实际损坏的案例。

4.2 磁盘空间检查:预留安全余量

变更操作(如索引重建、数据迁移、日志增长)可能瞬时消耗大量磁盘空间。检查应覆盖数据盘、日志盘、临时盘与归档盘。

  • 当前使用率:数据盘使用率 < 70%,日志盘使用率 < 60%。
  • 剩余空间值:至少保留变更预估消耗量的 2 倍 作为安全余量。
  • 增长趋势:查看过去24小时的空间增长曲线,排除因异常写入导致的“假性充足”。
# Linux 磁盘检查示例
df -h | grep -E '(data|log|archive)'
# 输出示例:
# /dev/sdb1  500G  320G  180G  64%  /data
# /dev/sdc1  200G  110G   90G  55%  /log

# 预估变更消耗:索引重建约需 20G 临时空间
# 安全判断:/data 剩余 180G > 20G * 2 = 40G ✅
#           /log  剩余  90G > 20G * 2 = 40G ✅

4.3 连接数监控:防止连接风暴

变更过程中,应用可能因重连、连接池膨胀或慢查询堆积导致连接数飙升。检查清单如下:

  • 当前活跃连接数:低于最大连接数的 60%。
  • 等待连接数:接近0,无大量连接处于 waiting 或 login 状态。
  • 连接来源分布:确认变更涉及的应用程序连接池已配置优雅重试,避免同步阻塞。
-- MySQL 连接数检查
SHOW VARIABLES LIKE 'max_connections';
SHOW STATUS LIKE 'Threads_connected';
SHOW STATUS LIKE 'Threads_running';

-- 结果示例:
-- max_connections: 500
-- Threads_connected: 280  (56% ✅)
-- Threads_running: 12     (正常)

4.4 慢查询审计:识别潜在风险

变更可能改变查询执行计划,导致原本正常的SQL变为慢查询。变更前应审计以下内容:

  • 慢查询日志:开启并检查最近1小时内超过阈值(如 100ms)的SQL。
  • 执行计划基线:对核心业务SQL,保存变更前的执行计划,用于变更后对比。
  • 锁等待分析:检查是否存在长时间未释放的锁或死锁历史。
审计脚本片段(MySQL):
-- 查看当前慢查询日志状态
SHOW VARIABLES LIKE 'slow_query_log%';
SHOW VARIABLES LIKE 'long_query_time';

-- 分析最近慢查询
SELECT 
  db, 
  ROUND(SUM(query_time), 2) AS total_query_time,
  COUNT(*) AS query_count,
  ROUND(AVG(query_time), 4) AS avg_query_time
FROM mysql.slow_log
WHERE start_time > NOW() - INTERVAL 1 HOUR
GROUP BY db
ORDER BY total_query_time DESC;

4.5 资源使用率评估:CPU、内存与I/O

资源使用率评估应基于 峰值时段 而非平均值。变更操作应避开资源瓶颈期。

资源指标 安全阈值 警告阈值 变更中止阈值
CPU 使用率 < 50% 50% – 75% > 75%
内存使用率 < 60% 60% – 80% > 80%
磁盘 I/O 等待时间 < 10ms 10ms – 30ms > 30ms
网络带宽使用率 < 40% 40% – 70% > 70%
# Linux 资源检查命令组合
# CPU 与负载
top -bn1 | head -5
# 内存
free -h
# 磁盘 I/O
iostat -x 1 3 | grep -E '(Device|sdb|sdc)'
# 网络
sar -n DEV 1 3 | grep -E '(eth0|ens)'

# 输出关键行示例:
# %Cpu(s): 35.2 us, 12.1 sy,  0.0 ni, 52.7 id  ✅
# Mem:       15G total,   8.5G used,   6.5G free  (56% ✅)
# Device:     rrqm/s  wrqm/s  r/s    w/s    r_await  w_await
# sdb:        0.00    0.00    120.0  80.0   5.2ms    8.1ms ✅

4.6 检查清单总览与决策流程

以下 SVG 图展示了变更前可靠性检查的完整流程与决策节点:

变更前可靠性检查决策流程 变更前可靠性检查决策流程 开始变更前检查 备份验证 完整性 + 恢复演练 磁盘空间 使用率 + 增长趋势 连接数监控 活跃 + 等待连接 慢查询审计 日志 + 执行计划 资源使用率 CPU/内存/I/O 全部通过? (无警告项) 继续执行变更 中止变更 / 回退 检查执行建议 • 每个检查项应设置明确的通过/警告/失败阈值,并记录检查时间与执行人。 • 警告项需在变更计划中标注风险缓解措施;失败项必须中止变更。 • 检查结果应归档至变更工单,作为事后审计的原始依据。 • 建议将检查脚本集成到自动化平台,减少人工遗漏风险。

4.7 检查清单速查表

以下表格汇总了五个检查域的核心命令与通过标准,可作为变更前的快速参考:

检查域 核心命令/工具 通过标准 失败处理
备份验证 RESTORE VERIFYONLY / pg_verifybackup 无损坏、日志链连续 重新备份并验证,否则中止
磁盘空间 df -h / iostat 使用率 < 70%,剩余 > 2倍预估消耗 清理空间或扩容后重检
连接数 SHOW STATUS / pg_stat_activity 活跃连接 < 60% max_connections 排查连接泄漏,强制清理空闲连接
慢查询审计 slow_log / pg_stat_statements 无新增慢查询,锁等待 < 1s 优化SQL或推迟变更
资源使用率 top / free / sar CPU < 50%,内存 < 60%,I/O < 10ms 等待资源回落或扩容
自动化集成提示:上述检查命令可以封装为 Shell 或 Python 脚本,在变更窗口开启前 15 分钟自动执行,并将结果推送至变更审批系统。对于未通过项,脚本应自动触发告警并锁定变更工单,防止人工跳过检查。