Skip to content

MySQL 故障处理流程规范

故障分类

按严重程度分类

严重程度描述影响范围响应时间
P0系统完全不可用全业务立即响应(15分钟内)
P1核心功能不可用核心业务4小时内响应
P2部分功能不可用非核心业务8小时内响应
P3性能问题系统性能下降24小时内响应
P4轻微问题无明显业务影响下一维护窗口

按故障类型分类

连接问题

  • 连接拒绝:无法建立MySQL连接
  • 连接超时:连接建立超时
  • 连接数耗尽:达到最大连接数限制
  • 连接异常断开:连接被异常终止

复制问题

  • 复制延迟:从库复制延迟增加
  • 复制中断:复制关系中断
  • 复制错误:复制过程中出现错误
  • 复制冲突:多源复制中的冲突

性能问题

  • CPU使用率高:MySQL进程CPU使用率高
  • 内存使用高:MySQL内存使用过高
  • I/O瓶颈:磁盘I/O性能瓶颈
  • 慢查询风暴:大量慢查询导致系统负载高

数据问题

  • 数据丢失:数据被意外删除或修改
  • 数据损坏:数据文件损坏
  • 数据不一致:主从数据不一致
  • 死锁:事务死锁

存储问题

  • 磁盘空间不足:存储空间耗尽
  • 磁盘故障:物理磁盘故障
  • 文件系统错误:文件系统损坏
  • 存储性能下降:存储I/O性能下降

网络问题

  • 网络延迟:网络传输延迟增加
  • 网络中断:网络连接中断
  • 网络丢包:网络数据包丢失
  • 网络拥塞:网络带宽不足

配置问题

  • 参数配置错误:MySQL参数配置不合理
  • 配置文件损坏:my.cnf文件损坏
  • 权限配置错误:用户权限配置错误

硬件问题

  • 服务器故障:物理服务器故障
  • 内存故障:服务器内存故障
  • CPU故障:服务器CPU故障
  • 电源故障:服务器电源故障

故障处理流程

1. 故障发现与报告

故障发现渠道

  • 监控系统告警:Zabbix、Prometheus等监控系统
  • 业务系统反馈:业务系统报错或性能下降
  • 用户投诉:最终用户反馈
  • 例行巡检:定期巡检发现

故障报告

  • 报告内容
    • 故障现象
    • 影响范围
    • 发生时间
    • 初步判断
  • 报告方式
    • 电话
    • 邮件
    • 即时通讯工具
    • 故障管理系统

故障等级确认

  • 评估影响:根据故障对业务的影响程度
  • 确定等级:按照严重程度分类确定故障等级
  • 升级机制:严重故障及时升级

2. 应急响应

成立应急小组

  • 组长:负责协调和决策
  • 技术专家:负责技术分析和处理
  • 业务代表:负责评估业务影响
  • 记录员:负责记录故障处理过程

应急准备

  • 工具准备:确保故障处理工具可用
  • 环境准备:准备测试环境
  • 备份确认:确认最近备份状态
  • 回滚方案:准备可能的回滚方案

业务影响评估

  • 影响范围:确定受影响的业务系统
  • 影响程度:评估业务损失
  • 恢复时间:预估故障恢复时间
  • 应急措施:制定业务应急措施

3. 故障排查

信息收集

系统信息
bash
# 查看系统状态
vmstat 1 5
mpstat 1 5
iosstat -x 1 5
top -b -n 1

# 查看MySQL进程状态
ps aux | grep mysql

# 查看网络状态
netstat -an | grep 3306
ss -an | grep 3306
MySQL信息
sql
-- 查看MySQL状态
SHOW GLOBAL STATUS;

-- 查看MySQL变量
SHOW GLOBAL VARIABLES;

-- 查看连接状态
SHOW PROCESSLIST;

-- 查看慢查询
SHOW GLOBAL STATUS LIKE '%slow%';

-- 查看InnoDB状态
SHOW ENGINE INNODB STATUS\G;

-- 查看复制状态
SHOW SLAVE STATUS\G;
日志信息
bash
# 查看MySQL错误日志
tail -n 100 /var/log/mysql/error.log

# 查看慢查询日志
tail -n 100 /var/log/mysql/slow-query.log

# 查看通用查询日志
tail -n 100 /var/log/mysql/general.log

# 查看系统日志
tail -n 100 /var/log/messages

根因分析

分析方法
  • 对比法:与正常状态对比
  • 排除法:逐步排除可能的原因
  • 假设法:提出假设并验证
  • 追踪法:追踪故障发生的完整链路
常见故障根因
故障现象可能原因检查方法
连接拒绝服务未启动、网络问题、权限问题`ps aux
复制中断网络问题、主库故障、数据冲突SHOW SLAVE STATUS\G
慢查询风暴索引失效、SQL语句问题、数据量增长SHOW PROCESSLISTEXPLAIN
磁盘空间不足日志增长、数据量增长、文件系统问题df -hdu -sh *
死锁事务设计问题、并发冲突SHOW ENGINE INNODB STATUS\G

4. 故障恢复

恢复方案

紧急恢复
  • 重启服务:适用于服务异常

    bash
    systemctl restart mysqld
  • 切换主库:适用于主库故障

    bash
    # 提升从库为主库
    STOP SLAVE;
    RESET MASTER;
  • 清理连接:适用于连接数耗尽

    sql
    -- 查看连接
    SHOW PROCESSLIST;
    -- 终止长时间运行的连接
    KILL process_id;
  • 释放空间:适用于磁盘空间不足

    bash
    # 清理二进制日志
    PURGE BINARY LOGS BEFORE '2023-01-01';
    # 清理慢查询日志
    echo > /var/log/mysql/slow-query.log
标准恢复
  • 从备份恢复

    bash
    # 停止服务
    systemctl stop mysqld
    # 恢复数据
    xtrabackup --copy-back --target-dir=/backup
    # 启动服务
    systemctl start mysqld
  • 复制重建

    bash
    # 停止从库
    STOP SLAVE;
    # 重置从库
    RESET SLAVE ALL;
    # 重新搭建复制
    CHANGE MASTER TO MASTER_HOST='master_host', MASTER_USER='repl', MASTER_PASSWORD='password', MASTER_LOG_FILE='binlog.000001', MASTER_LOG_POS=4;
    START SLAVE;
  • 参数调整

    sql
    -- 临时调整参数
    SET GLOBAL max_connections = 2000;
    SET GLOBAL innodb_buffer_pool_size = 8G;

恢复验证

功能验证
  • 服务状态

    bash
    systemctl status mysqld
    mysql -u root -p -e "SELECT 1;"
  • 业务功能

    • 执行核心业务操作
    • 验证数据完整性
    • 检查业务流程
性能验证
  • 性能指标

    sql
    SHOW GLOBAL STATUS LIKE '%Queries%';
    SHOW GLOBAL STATUS LIKE '%Threads%';
    SHOW GLOBAL STATUS LIKE '%Innodb%';
  • 响应时间

    • 测试业务响应时间
    • 对比历史性能数据
稳定性验证
  • 持续观察
    • 监控系统指标24小时
    • 检查错误日志
    • 验证复制状态

故障处理工具

监控工具

Zabbix

  • 功能:实时监控MySQL状态
  • 告警:基于阈值的告警
  • 图表:性能指标趋势图表
  • 集成:与其他系统集成

Prometheus + Grafana

  • 功能:时序数据监控
  • 告警:多维度告警规则
  • 可视化:丰富的仪表盘
  • 扩展性:易于扩展

Nagios

  • 功能:服务状态监控
  • 插件:丰富的MySQL监控插件
  • 告警:多种告警方式
  • 稳定性:成熟稳定

诊断工具

MySQLTuner

  • 功能:MySQL配置和性能分析
  • 使用
    bash
    wget https://raw.githubusercontent.com/major/MySQLTuner-perl/master/mysqltuner.pl
    perl mysqltuner.pl --user=root --pass=password

pt-tools

  • 功能:Percona Toolkit工具集
  • 组件
    • pt-summary:系统信息汇总
    • pt-mysql-summary:MySQL信息汇总
    • pt-stalk:监控MySQL性能
    • pt-deadlock-logger:死锁监控

innotop

  • 功能:InnoDB实时监控工具
  • 使用
    bash
    innotop --user=root --password=password

恢复工具

Percona XtraBackup

  • 功能:热备份工具
  • 使用
    bash
    # 备份
    xtrabackup --backup --target-dir=/backup
    # 恢复
    xtrabackup --copy-back --target-dir=/backup

mysqldump

  • 功能:逻辑备份工具
  • 使用
    bash
    # 备份
    mysqldump --all-databases --single-transaction > backup.sql
    # 恢复
    mysql < backup.sql

mysqlbinlog

  • 功能:二进制日志管理工具
  • 使用
    bash
    # 查看二进制日志
    mysqlbinlog binlog.000001
    # 恢复数据
    mysqlbinlog binlog.000001 | mysql

故障处理案例

案例1:连接数耗尽

故障现象

  • 应用无法连接MySQL
  • 错误信息:Too many connections
  • 监控显示连接数达到最大值

处理过程

  1. 紧急处理

    sql
    -- 查看连接
    SHOW PROCESSLIST;
    -- 终止空闲连接
    KILL process_id;
    -- 临时增加连接数
    SET GLOBAL max_connections = 2000;
  2. 根因分析

    • 连接池配置不合理
    • 应用未正确释放连接
    • 长时间运行的查询
  3. 修复措施

    • 优化连接池配置
    • 修复应用连接释放问题
    • 优化慢查询
    • 调整max_connections参数

案例2:主从复制中断

故障现象

  • 从库复制状态异常
  • 错误信息:Error executing row event
  • 监控显示复制延迟增加

处理过程

  1. 紧急处理

    sql
    -- 查看复制状态
    SHOW SLAVE STATUS\G;
    -- 跳过错误(谨慎使用)
    SET GLOBAL sql_slave_skip_counter = 1;
    START SLAVE;
  2. 根因分析

    • 主库数据与从库不一致
    • 从库应用二进制日志失败
    • 网络中断导致复制异常
  3. 修复措施

    • 重建复制
    • 检查数据一致性
    • 优化网络连接
    • 配置半同步复制

案例3:慢查询风暴

故障现象

  • MySQL CPU使用率高
  • 应用响应缓慢
  • 监控显示大量慢查询

处理过程

  1. 紧急处理

    sql
    -- 查看慢查询
    SHOW PROCESSLIST;
    -- 终止慢查询
    KILL process_id;
    -- 启用慢查询日志
    SET GLOBAL slow_query_log = 1;
  2. 根因分析

    • 索引失效
    • SQL语句优化不当
    • 数据量增长导致执行计划变化
  3. 修复措施

    • 添加缺失索引
    • 优化SQL语句
    • 分析执行计划
    • 考虑分区表

故障处理最佳实践

预防措施

定期检查

  • 配置检查

    bash
    # 使用MySQLTuner检查配置
    perl mysqltuner.pl
  • 性能检查

    sql
    -- 查看性能指标
    SHOW GLOBAL STATUS LIKE '%performance%';
  • 安全检查

    sql
    -- 检查用户权限
    SELECT user, host FROM mysql.user;

备份策略

  • 全量备份:每周一次
  • 增量备份:每天一次
  • 二进制日志:保留至少7天
  • 异地备份:定期复制到异地

监控优化

  • 关键指标

    • 连接数
    • 查询响应时间
    • 复制状态
    • 磁盘空间
    • 系统资源使用
  • 告警阈值

    • 连接数:80%阈值
    • CPU使用率:90%阈值
    • 磁盘空间:85%阈值
    • 复制延迟:300秒阈值

处理技巧

快速定位

  • 使用工具

    • SHOW PROCESSLIST:查看当前连接
    • SHOW ENGINE INNODB STATUS:查看InnoDB状态
    • EXPLAIN:分析SQL执行计划
  • 日志分析

    • 错误日志:查找错误信息
    • 慢查询日志:分析性能问题
    • 二进制日志:分析数据变更

避免误操作

  • 确认操作

    • 执行前确认操作影响
    • 备份关键数据
    • 记录操作步骤
  • 回滚计划

    • 准备回滚方案
    • 测试回滚操作
    • 确认回滚时间

团队协作

  • 明确分工

    • 负责人:协调整体
    • 技术专家:负责技术处理
    • 业务代表:评估业务影响
    • 记录员:记录处理过程
  • 沟通机制

    • 定期会议
    • 实时通讯
    • 共享文档

故障处理培训

培训内容

技术培训

  • MySQL基础知识

    • 架构
    • 配置
    • 性能优化
  • 故障处理技术

    • 诊断方法
    • 恢复技术
    • 工具使用

流程培训

  • 故障处理流程

    • 流程步骤
    • 角色职责
    • 沟通机制
  • 案例分析

    • 真实案例
    • 模拟演练
    • 经验分享

培训方法

理论培训

  • 课堂培训

    • 讲师授课
    • 教材学习
    • 在线课程
  • 文档学习

    • 故障处理手册
    • 知识库
    • 技术博客

实践培训

  • 模拟演练

    • 故障模拟
    • 应急响应演练
    • 团队协作演练
  • 实际操作

    • 参与真实故障处理
    • 影子学习
    • 导师指导

培训评估

  • 知识测试

    • 理论考试
    • 技能评估
    • 案例分析
  • 实践评估

    • 演练表现
    • 实际操作能力
    • 团队协作能力

故障处理自动化

自动化工具

脚本自动化

  • 监控脚本

    • 定期检查MySQL状态
    • 自动发送告警
    • 生成报告
  • 处理脚本

    • 自动清理连接
    • 自动重建复制
    • 自动释放空间

工具集成

  • Ansible

    • 自动化配置管理
    • 批量执行命令
    • 故障处理流程自动化
  • Jenkins

    • 自动化任务调度
    • 集成测试
    • 持续部署

自动化流程

故障检测

  • 实时监控
    • 自动检测异常
    • 智能告警
    • 故障分类

故障处理

  • 自动响应
    • 执行预定义脚本
    • 尝试自动恢复
    • 升级严重故障

常见问题(FAQ)

Q1: 如何快速判断MySQL故障的严重程度?

A1: 判断故障严重程度的方法:

  1. 影响范围

    • 全业务影响:P0
    • 核心业务影响:P1
    • 部分业务影响:P2
    • 性能影响:P3
    • 轻微影响:P4
  2. 响应时间

    • 立即响应:P0-P1
    • 工作日响应:P2-P3
    • 维护窗口响应:P4
  3. 恢复难度

    • 需要重建服务:P0-P1
    • 需要优化配置:P2-P3
    • 需要轻微调整:P4

Q2: 故障处理过程中如何确保数据安全?

A2: 确保数据安全的措施:

  1. 备份

    • 故障处理前确认最近备份状态
    • 重要操作前进行额外备份
    • 保存二进制日志
  2. 操作谨慎

    • 执行前评估操作影响
    • 使用事务保证操作原子性
    • 记录所有操作步骤
  3. 验证

    • 恢复后验证数据完整性
    • 检查业务功能是否正常
    • 监控数据一致性

Q3: 如何避免故障处理过程中的二次故障?

A3: 避免二次故障的方法:

  1. 充分准备

    • 制定详细的处理计划
    • 准备回滚方案
    • 验证工具可用性
  2. 谨慎操作

    • 逐步执行操作
    • 每步操作后验证
    • 避免同时执行多个高风险操作
  3. 团队协作

    • 多人审核关键操作
    • 明确分工
    • 及时沟通

Q4: 故障处理后如何验证系统稳定性?

A4: 验证系统稳定性的方法:

  1. 功能验证

    • 执行核心业务流程
    • 验证所有功能模块
    • 测试边界情况
  2. 性能验证

    • 运行性能测试
    • 对比历史性能数据
    • 检查资源使用情况
  3. 持续监控

    • 24小时监控系统状态
    • 检查错误日志
    • 验证复制状态

Q5: 如何建立有效的故障预防机制?

A5: 建立故障预防机制的步骤:

  1. 监控优化

    • 完善监控指标
    • 调整告警阈值
    • 建立预警机制
  2. 定期检查

    • 配置检查
    • 性能检查
    • 安全检查
  3. 自动修复

    • 配置自动清理脚本
    • 实现自动故障转移
    • 建立自愈机制
  4. 知识积累

    • 记录故障案例
    • 定期培训
    • 持续改进

Q6: 如何处理MySQL集群故障?

A6: 处理MySQL集群故障的方法:

  1. 故障隔离

    • 识别故障节点
    • 隔离故障节点
    • 确保其他节点正常运行
  2. 角色切换

    • 主库故障:提升从库
    • 从库故障:重建从库
    • 网络分区:处理脑裂
  3. 集群恢复

    • 修复故障节点
    • 重新加入集群
    • 验证集群状态

Q7: 如何处理MySQL数据损坏故障?

A7: 处理数据损坏故障的方法:

  1. 紧急处理

    • 停止服务防止进一步损坏
    • 备份损坏的数据文件
    • 尝试使用innodb_force_recovery
  2. 恢复方案

    • 从最近备份恢复
    • 应用二进制日志
    • 使用innodb repair工具
  3. 验证修复

    • 检查数据完整性
    • 验证业务功能
    • 优化备份策略

Q8: 如何提高团队的故障处理能力?

A8: 提高团队故障处理能力的措施:

  1. 培训

    • 技术培训
    • 流程培训
    • 案例分析
  2. 演练

    • 模拟故障演练
    • 应急响应演练
    • 团队协作演练
  3. 知识管理

    • 建立知识库
    • 文档共享
    • 经验总结
  4. 工具使用

    • 熟悉故障处理工具
    • 自动化工具使用
    • 监控工具配置
  5. 持续改进

    • 定期复盘
    • 流程优化
    • 技术创新