InnoDB: Database was not shutdown normally!

原创于 2025-09-28 18:31:08 发布 · 1.3k 阅读

8 ·

CC 4.0 BY-SA版权

文章标签：

#数据库

MySQL 专栏收录该内容

173 篇文章

订阅专栏

MySQL 数据库崩溃分析报告

概述

MySQL 数据库在运行期间发生多次异常崩溃和重启，导致服务不稳定，客户端连接被拒绝。

问题时间线

事件序列

T1 时刻 - 首次崩溃恢复
- 数据库非正常关闭
- 开始崩溃恢复流程
- 发现1个未完成事务需要回滚
T2 时刻 - 第二次崩溃
- 数据库再次非正常关闭
- 检测到数据页损坏
- 发现3个XA事务处于prepared状态
T2+20秒 - 服务异常停止
- 服务启动后立即执行shutdown
- 未进行正常的buffer pool flush
T2+20秒 - 第三次崩溃恢复
- 再次进入崩溃恢复模式
- 数据页损坏问题持续存在

主要问题分析

1. 服务稳定性问题

症状

MySQL服务在短时间内多次崩溃重启
崩溃之间没有正常的shutdown日志
每次重启都显示 “Database was not shutdown normally!”

可能原因

内存不足（OOM Killer） - 最可能的原因
系统资源耗尽
硬件故障
进程被强制终止（kill -9）

2. 数据完整性问题

InnoDB数据页损坏

Warning: Page XXX in the doublewrite buffer is not within space bounds
- 影响表空间: space=70
- 损坏页面数: 4个

未完成的分布式事务

3个XA事务处于prepared状态
事务ID: 270646XXX系列
需要手动介入处理

3. TLS配置问题

现象

大量TLS 1.1连接警告
系统要求使用TLS 1.2或更高版本
所有问题连接来自同一客户端IP

影响

可能导致连接被拒绝
存在安全风险

4. 配置文件问题

缺失的buffer pool文件

ERROR: Cannot open '/var/lib/mysql/data/innodb_ts/ib_buffer_pool' for reading

过时的配置参数

avoid_temporal_upgrade (已弃用)
show_old_temporals (已弃用)
metadata_locks_cache_size (已弃用)

根本原因分析

最可能的崩溃原因：内存耗尽

证据链：

突然的进程终止（无正常shutdown）
InnoDB buffer pool 配置为1.75G
多个并发连接和事务
数据写入中断导致页面损坏

触发条件

内存使用超过系统限制
Linux OOM Killer介入
MySQL进程被强制终止
数据文件写入中断

解决方案

紧急措施

验证崩溃原因

# 检查OOM日志
dmesg | grep -i "killed process"
journalctl -xe | grep -i "out of memory"

# 检查系统资源
free -h
df -h

修复数据完整性

# 检查并修复数据库
mysqlcheck --all-databases --check --auto-repair

# 处理XA事务
mysql> XA RECOVER;
mysql> XA COMMIT 'xid' / XA ROLLBACK 'xid';

临时稳定服务

# 重启MySQL服务
systemctl restart mysql

# 监控服务状态
systemctl status mysql
tail -f /var/log/mysql/error.log

长期优化

1. 内存优化

[mysqld]
# 根据实际内存调整
innodb_buffer_pool_size = 1G
innodb_buffer_pool_instances = 2
max_connections = 100
thread_cache_size = 8

2. TLS配置升级

[mysqld]
# 只允许安全的TLS版本
tls_version = TLSv1.2,TLSv1.3

3. 监控和告警

配置内存使用率监控（阈值：80%）
配置磁盘空间监控（阈值：85%）
配置MySQL进程存活监控
设置自动重启策略

4. 备份策略

实施定期全量备份
配置binlog增量备份
测试恢复流程

预防措施

系统层面

增加swap空间

# 创建4G swap文件
dd if=/dev/zero of=/swapfile bs=1G count=4
chmod 600 /swapfile
mkswap /swapfile
swapon /swapfile

调整OOM配置

# 降低MySQL被OOM killer选中的概率
echo -1000 > /proc/$(pidof mysqld)/oom_score_adj

数据库层面

优化查询
- 添加必要索引
- 优化慢查询
- 限制大结果集
连接池管理
- 使用连接池
- 设置合理的超时时间
- 限制并发连接数
定期维护
- 定期分析表
- 清理无用数据
- 优化表碎片

监控指标

关键指标

内存使用率 < 80%
连接数 < max_connections * 0.8
磁盘I/O延迟 < 20ms
慢查询数量 < 10/分钟

告警阈值

指标	警告	严重
内存使用率	70%	85%
磁盘使用率	75%	90%
连接数占比	60%	80%
响应时间	1s	3s

总结

数据库崩溃的主要原因是系统资源（很可能是内存）耗尽导致MySQL进程被强制终止。建议：

立即增加系统内存或优化MySQL内存配置
修复数据完整性问题
升级TLS配置到1.2+
实施完善的监控和备份策略

附录：常用排查命令

# 系统资源检查
free -h
vmstat 1 10
iostat -x 1 10
top -b -n 1

# MySQL状态检查
mysql -e "SHOW PROCESSLIST;"
mysql -e "SHOW ENGINE INNODB STATUS\\G"
mysql -e "SHOW VARIABLES LIKE '%buffer%';"
mysql -e "SHOW GLOBAL STATUS LIKE '%conn%';"

# 日志分析
tail -f /var/log/mysql/error.log
grep -i error /var/log/mysql/error.log | tail -50
journalctl -u mysql --since "1 hour ago"