印刻数据库

外观

PostgreSQL 故障分类与分级 ​

故障分类 ​

1. 按故障影响范围分类 ​

单实例故障 ​

  • 定义：仅影响单个PostgreSQL实例的故障
  • 表现：单节点数据库无法访问，其他节点正常运行
  • 示例：单个实例崩溃、磁盘损坏、网络中断

集群故障 ​

  • 定义：影响整个PostgreSQL集群的故障
  • 表现：集群所有节点无法正常提供服务
  • 示例：共享存储故障、网络分区、集群管理软件故障

业务影响故障 ​

  • 定义：导致业务系统无法正常运行的故障
  • 表现：业务应用无法访问数据库，或访问异常
  • 示例：慢查询风暴、死锁、主从切换失败

2. 按故障性质分类 ​

硬件故障 ​

  • CPU故障：CPU使用率过高、CPU损坏
  • 内存故障：内存不足、内存损坏、内存泄漏
  • 存储故障：磁盘损坏、磁盘满、存储阵列故障
  • 网络故障：网络中断、网络延迟、网络抖动
  • 电源故障：服务器断电、UPS故障

软件故障 ​

  • 数据库内核故障：PostgreSQL进程崩溃、核心bug
  • 配置错误：参数配置不当、配置文件损坏
  • 应用层故障：SQL错误、连接池配置错误
  • 中间件故障：pgpool-II故障、Patroni故障

人为故障 ​

  • 误操作：误删除数据、误修改配置、误执行DROP命令
  • 维护失误：升级失败、备份恢复失败
  • 安全事件：黑客攻击、权限泄露

3. 按故障持续时间分类 ​

瞬态故障 ​

  • 定义：持续时间短，自行恢复或简单处理即可恢复的故障
  • 示例：网络闪断、临时锁等待、进程短暂挂起

持续性故障 ​

  • 定义：需要人工干预才能恢复的故障
  • 示例：磁盘损坏、数据 corruption、配置错误

故障分级标准 ​

1. 级别定义 ​

P0级（灾难性故障） ​

  • 影响：核心业务完全中断，无法提供服务
  • 范围：所有用户或关键业务部门
  • 持续时间：预计恢复时间超过2小时
  • 示例：
    • 主库完全崩溃，无可用备用库
    • 核心表数据丢失且无法恢复
    • 整个集群不可用

P1级（重大故障） ​

  • 影响：核心业务部分中断，或非核心业务完全中断
  • 范围：部分用户或业务部门
  • 持续时间：预计恢复时间1-2小时
  • 示例：
    • 主库崩溃，但备用库可用，需要切换
    • 核心表索引损坏，影响查询性能
    • 部分业务功能不可用

P2级（重要故障） ​

  • 影响：业务性能下降，或非核心功能中断
  • 范围：少数用户或特定功能
  • 持续时间：预计恢复时间30分钟-1小时
  • 示例：
    • 慢查询风暴导致系统响应缓慢
    • 单个辅助功能不可用
    • 备份失败

P3级（一般故障） ​

  • 影响：系统轻微异常，不影响业务正常运行
  • 范围：个别用户或后台功能
  • 持续时间：预计恢复时间30分钟以内
  • 示例：
    • 单个连接失败
    • 非核心日志告警
    • 配置轻微不当

2. 分级依据 ​

分级依据P0级P1级P2级P3级
业务影响范围全部核心业务部分核心业务/全部非核心业务少数业务功能个别功能
用户影响数量全部用户部分用户少数用户个别用户
恢复时间预期>2小时1-2小时30分钟-1小时<30分钟
数据丢失风险高中低无
紧急程度最高高中低

故障处理流程 ​

1. 故障发现 ​

bash
# 监控系统告警
# 例如Zabbix、Prometheus告警

# 日志分析
cat /var/log/postgresql/postgresql-15-main.log | grep -i error

# 手动检查
psql -c "SELECT * FROM pg_stat_activity WHERE state = 'active';"

2. 故障分级 ​

  • 根据故障影响范围、业务重要性、恢复时间预期进行分级
  • 确定故障级别后，启动相应的处理流程
  • 及时通知相关人员

3. 故障处理 ​

故障级别处理责任人响应时间处理要求
P0级高级DBA + 架构师立即24小时值班，成立应急小组，每15分钟汇报一次进度
P1级DBA主管 + 资深DBA15分钟内优先处理，每30分钟汇报一次进度
P2级资深DBA30分钟内正常工作时间内处理，每小时汇报一次进度
P3级初级DBA2小时内工作时间内处理，定期汇报

4. 故障恢复 ​

  • 执行恢复操作（如主从切换、数据恢复、配置修复等）
  • 验证恢复结果
  • 恢复业务访问

故障分级管理最佳实践 ​

1. 建立明确的分级标准 ​

  • 与业务部门共同制定故障分级标准
  • 定期回顾和更新分级标准
  • 确保分级标准与业务重要性匹配

2. 建立高效的告警机制 ​

  • 根据故障级别设置不同的告警方式（邮件、短信、电话）
  • 为不同级别故障设置不同的告警接收人
  • 实现告警抑制和聚合，避免告警风暴

3. 建立快速响应机制 ​

  • 制定不同级别故障的处理流程
  • 建立24小时值班制度
  • 准备应急响应工具和脚本

4. 建立完善的知识库 ​

  • 记录历史故障案例
  • 分析故障根因和解决方案
  • 定期组织故障复盘会议
  • 持续优化故障处理流程

5. 定期演练 ​

  • 定期进行故障演练
  • 模拟不同级别的故障场景
  • 测试故障处理流程和响应时间
  • 评估演练结果，持续改进

常见故障场景与分级示例 ​

1. 主库崩溃，无备用库 ​

  • 分级：P0级
  • 影响：核心业务完全中断
  • 处理：立即启动应急恢复流程，使用备份恢复数据

2. 主库崩溃，备用库可用 ​

  • 分级：P1级
  • 影响：核心业务短暂中断
  • 处理：执行主从切换，恢复业务访问

3. 慢查询风暴导致系统响应缓慢 ​

  • 分级：P2级
  • 影响：业务性能下降
  • 处理：定位慢查询，优化或终止慢查询

4. 单个表索引损坏 ​

  • 分级：P2级
  • 影响：部分查询性能下降
  • 处理：重建损坏的索引

5. 日志告警：磁盘空间不足 ​

  • 分级：P3级
  • 影响：系统轻微异常
  • 处理：清理日志或扩展磁盘空间

常见问题（FAQ） ​

Q1：如何准确判断故障级别？ ​

A1：判断故障级别应考虑以下因素：

  • 故障影响的业务范围
  • 受影响的用户数量
  • 预计恢复时间
  • 数据丢失风险
  • 业务重要性

建议与业务部门共同制定明确的分级标准，并定期回顾和更新。

Q2：故障分级后如何通知相关人员？ ​

A2：根据故障级别设置不同的通知方式：

  • P0级：电话+短信+邮件，通知所有相关人员
  • P1级：短信+邮件，通知DBA团队和业务负责人
  • P2级：邮件，通知DBA团队
  • P3级：邮件，通知值班DBA

Q3：如何缩短故障恢复时间？ ​

A3：缩短故障恢复时间的建议：

  • 建立完善的监控和告警机制
  • 制定详细的故障处理流程
  • 准备应急响应工具和脚本
  • 定期进行故障演练
  • 建立完善的知识库
  • 培养经验丰富的DBA团队

Q4：如何避免误判故障级别？ ​

A4：避免误判故障级别的建议：

  • 建立明确的分级标准和判断流程
  • 与业务部门保持良好沟通
  • 定期组织故障分级培训
  • 建立故障分级审核机制
  • 持续优化分级标准

Q5：故障分级管理的目的是什么？ ​

A5：故障分级管理的主要目的：

  • 提高故障响应效率
  • 合理分配资源
  • 确保核心业务优先恢复
  • 便于绩效考核和改进
  • 建立规范的故障管理流程
  • 提高业务连续性