这是一个创建于 1428 天前的主题，其中的信息可能已经有所发展或是发生改变。
一、事由：主力 Mysql 数据突然巨量占满空间而停摆
空间占满 100G 后，再度占满 170G，冒了一阵冷汗，以为受攻击，如下图
二、时间点回顾
- 15 点，发现数据库占满 100G 空间，查了实际数据库文件大小才 11G
- 虽觉意外，为恢复正常，还是先加空间（还好是 RDS 云数据库，硬盘扩展方便）
- 空间加到 170G，数据库恢复正常，然后就找日志表来清，想缩减下空间占用
- 删除了不少日志表(使用 truncate 清表)，也看到空间占用微微在下降
- 还有一张千成级的日志表，准备要清掉，结果开发说，要留下本月的数据，于是就用 delete+optimize 方式 : delete from ###_logs where id < ####, 结果十几分钟没有结果返回
- 最后跟开发协调，还是把这张表全清了，还是用 truncate 清表，瞬间清掉了
- 查看数据库的空间占用，好像没降多少空间
- 大概过了十几分钟，进入数据库面板，发现空间再度被占满，有点急了，第一反应是不是被攻击了
- 查数据库文件，还是 11G，那为什么会占满 170G
- 于是又再次增加空间，并关掉远程连接，把疑似问题账号关了
- 重启数据库
- 结果数据库空间占用回到 20G， 一切又正常了
三、事故排查
- 是否受攻击：仔细看了网络连接情况，正常，排除了攻击
- 慢查询监控：近期有不少慢查询记录，估计慢查询会产生 temp 临时文件
- 数据库实例两年多没有重启过，网上说 mysql5.7 默认情况，不重启的话，临时文件会一直累积
- 千万级表 delete 产生大量临时文件
- 重启 mysql 实例是最有效的清临时文件方式
 |
1
hbolive 2020-12-24 11:36:36 +08:00
如果是偶尔的，估计是某个操作导致慢查询产生巨量临时文件。。
|
 |
2
angeltop 2020-12-24 11:44:40 +08:00
检查检查临时表大小
|
 |
3
neocanable 2020-12-24 13:32:19 +08:00
innodb 的话，把 innodb_file_per_table 打开了吧，这样的话 truncate 才会起作用
|
 |
4
kaka6 OP 按目前来说，最有效的就是重启
因为平常 left join , group by 或者 where 查询等，只要没有建索引(物理文件)，都会生成临时文件或临时空间 而这个临时文件不会自动释放(我以前一直觉得会释放) 运行久了，累积的临时文件就会占满空间 所以目前觉得最有效的就是定期重启 mysql 实例 当然代码、数据结构也得优化，该建索引建索引 欢迎各位沟通关于 mysql 的其它运维技巧 |
 |
5
opengps 2020-12-24 13:58:40 +08:00
所有的表数据大小统计一下，看看实际数据占用大小
如果数据大小占比很小，那可能真的是 mysql 日志或者索引等用途占用了，得查查索引之类的使用问题了 |
|
6
kaka6 OP @opengps 所有表数据只占 11G, 结果因为其它空间，居然占满了 170G， 不可思义
从昨天重启完到现在，总空间只有 20G，稳定不变了，接下来还是得好好多观察 |
 |
7
han3sui 2020-12-24 15:03:02 +08:00
看完感觉云数据库好方便
|
 |
8
daytonight 2020-12-24 16:06:00 +08:00 via Android
用 alter table t engine = innodb;重建下表试试。
|
 |
9
weifan 2020-12-24 16:22:46 +08:00
为什么你能发图片
|
|
10
kaka6 OP @daytonight 全部表已经都是 innodb
|
 |
12
yfwl 2020-12-25 03:03:48 +08:00
所以我想问除了重启还有没有不停止服务去清理的方法？
|
 |
13
muskill 2020-12-25 08:18:28 +08:00 via iPhone
|
 |
14
simonlu9 2020-12-25 09:30:49 +08:00
千万不要在线上删大量数据，会产生很大 undo 和 redo 空间，执行超慢，还是分批删吧
|
Select Language