MySQL故障排查与运维案例详解
更新时间:2026年04月13日 09:16:42 作者:SPC的存折
文章讨论了MySQL故障排查与运维案例,涵盖了连接类、性能类、复制类、数据恢复类、高可用故障、存储引擎故障、内存问题、安全相关、备份恢复、升级问题、配置错误等多方面的故障排查和优化方案,同时提到了一些关键监控指标和灾难恢复流程,感兴趣的朋友跟随小编一起看看吧
MySQL故障排查与运维案例全集
一、连接类故障
1. 连接超时
现象:ERROR 2003 (HY000): Can't connect to MySQL server on 'host' (110 "Connection timed out")
排查流程:
# 检查网络连通性 nc -zv host 3306 mtr host # 检查防火墙 iptables -L -n | grep 3306 # 验证连接数限制 SHOW VARIABLES LIKE 'max_connections'; SHOW STATUS LIKE 'Threads_connected';
2. 认证失败
案例:升级后密码策略变更导致应用连接失败
解决方案:
-- 创建传统认证用户 CREATE USER 'appuser'@'%' IDENTIFIED WITH mysql_native_password BY 'password'; -- 临时降低密码强度 SET GLOBAL validate_password_policy=LOW;
二、性能类故障
1. CPU 100%问题
诊断步骤:
-- 查找高消耗SQL SELECT * FROM sys.processlist WHERE COMMAND != 'Sleep' ORDER BY TIME DESC; -- 使用Performance Schema SELECT * FROM performance_schema.threads WHERE PROCESSLIST_TIME > 60\G -- 分析慢查询 SHOW ENGINE INNODB STATUS;
2. 慢查询优化案例
场景:订单查询超时
调优方案:
-- 添加复合索引
ALTER TABLE orders ADD INDEX idx_customer_status (customer_id, status);
-- 重写查询语句
SELECT /*+ INDEX(idx_customer_status) */ * FROM orders
WHERE customer_id=123 AND status IN ('shipped','completed');三、复制类故障
1. 主从数据不一致
检测工具:
# 安装校验工具 wget https://downloads.percona.com/downloads/percona-toolkit/3.5.0/binary/tarball/percona-toolkit-3.5.0_x86_64.tar.gz # 数据一致性校验 pt-table-checksum -h master -u user -p pass --databases mydb
2. 主从延迟
优化方案:
# my.cnf 优化 [mysqld] slave_parallel_workers = 8 slave_pending_jobs_size_max = 2G innodb_flush_log_at_trx_commit = 0 sync_binlog = 1000
四、数据恢复类
1. 误删除恢复
步骤:
# 停止MySQL服务 systemctl stop mysqld # 使用mysqlbinlog恢复 mysqlbinlog --start-position=107 /var/log/mysql-bin.000001 | mysql -uroot -p # 使用延时从库恢复 STOP SLAVE; CHANGE MASTER TO MASTER_DELAY = 3600; START SLAVE;
2. 分区表数据丢失
案例:DROP PARTITION误操作
解决方案:
-- 从备份恢复单分区
ALTER TABLE logs IMPORT PARTITION p202301
FROM '/backup/202301_partition.ibd';
五、高可用故障
1. MHA切换失败
诊断流程:
# 检查SSH互信 masterha_check_ssh --conf=/etc/mha/app1.cnf # 检查复制健康 masterha_check_repl --conf=/etc/mha/app1.cnf # 查看管理日志 tail -f /var/log/masterha/app1/manager.log
2. InnoDB Cluster脑裂
修复方案:
-- 强制重启集群
dba.rebootClusterFromCompleteOutage('cluster1');
-- 人工重新组集群
SELECT * FROM performance_schema.replication_group_members;六、存储引擎故障
1. InnoDB损坏修复
修复步骤:
# 强制恢复模式启动 innodb_force_recovery = 6 # 导出数据 mysqldump -uroot -p --all-databases > full_backup.sql # 重建数据库 mysql_install_db --user=mysql systemctl start mysqld mysql -uroot -p < full_backup.sql
七、内存问题
1. OOM崩溃
优化方案:
# my.cnf内存优化 [mysqld] innodb_buffer_pool_size=64G key_buffer_size=0 query_cache_size=0 table_open_cache=20000
八、安全相关
1. 入侵检测
处理流程:
-- 查找异常账号 SELECT * FROM mysql.user WHERE authentication_string='' \G -- 检查数据库文件权限 ls -l /var/lib/mysql -- 审计可疑操作 mysqlbinlog /var/log/mysql-bin.000007 | grep -i 'ALTER\|CREATE\|DROP'
九、备份恢复
1. 大库备份优化
# Xtrabackup部分备份 xtrabackup --backup --databases="db1 db2" --target-dir=/backup/partial # mysqldump分片备份 mysqldump -uroot -p db1 | split -b 2G - db1_part_
十、升级问题
1. 5.7升级8.0兼容问题
解决方案:
-- 开启兼容SQL模式 SET GLOBAL sql_mode = 'NO_ENGINE_SUBSTITUTION'; -- 移除废弃功能 ALTER TABLE mytable ROW_FORMAT=DYNAMIC;
十一、配置错误
1. 参数误设置
恢复方法:
# 安全模式启动,高版本中不可用 mysqld_safe --skip-grant-tables --skip-networking & # 重置配置 SET GLOBAL max_connections=100; FLUSH PRIVILEGES;
十二、工具速查表
| 工具名称 | 使用场景 | 命令示例 |
|---|---|---|
| pt-query-digest | 慢日志分析 | pt-query-digest slow.log > report.txt |
| mysqladmin | 进程管理 | mysqladmin -u root -p processlist |
| Percona Toolkit | 运维工具包 | pt-online-schema-change |
| Mylogger | 实时审计 | mylogger -u root -p pass -h localhost |
| MySQL Shell | InnoDB Cluster管理 | dba.checkInstanceConfiguration() |
十三、关键监控指标
| 指标 | 报警阈值 | 获取方式 |
|---|---|---|
| 连接使用率 | > 85% | Threads_connected/max_connections |
| 复制延迟(秒) | > 60 | SHOW SLAVE STATUS |
| InnoDB缓冲池命中率 | < 95% | (1 - Innodb_pages_read/Innodb_buffer_pool_read_requests)*100 |
| 临时表磁盘使用 | > 1G | Created_tmp_disk_tables |
| 锁等待时间(秒) | > 5 | SHOW ENGINE INNODB STATUS |
十四、灾难恢复流程
- 立即停止服务:
systemctl stop mysqld - 保护现场:拷贝数据目录和日志文件
- 评估损坏:
innochecksum -v /var/lib/mysql/ibdata1 mysqlcheck --all-databases
- 选择恢复方案:
- 从主备份恢复
- 使用Binlog增量恢复
- 重建数据库结构
- 验证完整性:
pt-table-checksum - 灰度恢复服务
十五、最佳实践总结
- 备份策略:
- 每天全备 + Binlog实时同步
- 备份恢复演练每月一次
- 高可用架构:

- 参数调优原则:
- buffer_pool_size = 系统内存的70-80%
- max_connections = (最大连接数+冗余)
- sync_binlog = 1 (数据安全) / 1000 (性能优先)
- 安全基线:
- 禁用local-infile
- 删除test数据库
- 启用SSL连接
- 审计插件开启
黄金准则:
- 任何参数修改前进行
SET GLOBAL测试- 维护窗口操作必须有回滚计划
- 生产环境变更遵循"变更三板斧":方案评审->灰度实施->结果验证
到此这篇关于MySQL故障排查与运维案例的文章就介绍到这了,更多相关mysql故障排查与运维内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家!
相关文章
解决Windows10下mysql5.5数据库命令行中文乱码问题
重置系统后,很久之前安装的MySQL数据库出现了控制台查询中文乱码问题,时间太久早已经不记得怎么设置了。下面通过本文给大家分享Windows10下解决MySQL5.5数据库命令行中文乱码问题,一起看看吧2017-07-07
深入解析mysql中order by与group by的顺序问题
本篇文章是对mysql中order by与group by的顺序问题进行了详细的分析介绍,需要的朋友参考下2013-06-06


最新评论